Hello,

We were going to submit plPHP to core for inclusion but it is not ready
yet. Namely it requires the apache SAPI which could introduce some
portability issues. The other issues it has (such as some array parsing
problems) are minor and could probably be fixed easily within the beta
period but the SAPI is a show stopper.

As some of you know, we have also procured permission to relicense
plRuby so that the project can include it in core. I have a version that
works with -HEAD.

However plRuby is even a stranger beast as it uses an entirely ruby
build system. I am also fairly confident that it does not meat the
PostgreSQL style guidelines.

Is there enough interest in plRuby to get it where it needs to be for
possible inclusion into core?

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Sun, 16 Jul 2006, Joshua D. Drake wrote:

> Hello,
>
> However plRuby is even a stranger beast as it uses an entirely ruby
> build system. I am also fairly confident that it does not meat the
> PostgreSQL style guidelines.

Well... JDBC used its own.

>
> Is there enough interest in plRuby to get it where it needs to be for
> possible inclusion into core?

I'd like to see it ship with the core distribution.

Thanks,

Gavin

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake:
> We were going to submit plPHP to core for inclusion but it is not ready
> yet.

> Is there enough interest in plRuby to get it where it needs to be for
> possible inclusion into core?

Considering that PL/Java effectively just got shot down, I don't see any hope
for these.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Peter Eisentraut wrote:

>Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake:
>
>
>>We were going to submit plPHP to core for inclusion but it is not ready
>>yet.
>>
>>
>
>
>
>>Is there enough interest in plRuby to get it where it needs to be for
>>possible inclusion into core?
>>
>>
>
>Considering that PL/Java effectively just got shot down, I don't see any hope
>for these.
>
>
>

But the reasons that applied to PL/Java (masses of non-C code was the
main one) probably don't apply in these 2 cases.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut wrote:
> Am Montag, 17. Juli 2006 03:18 schrieb Joshua D. Drake:
>> We were going to submit plPHP to core for inclusion but it is not ready
>> yet.
>
>> Is there enough interest in plRuby to get it where it needs to be for
>> possible inclusion into core?
>
> Considering that PL/Java effectively just got shot down, I don't see any hope
> for these.

PLRuby is written in C.

Sincerely,

Joshua D. Drake




--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew Dunstan wrote:
> But the reasons that applied to PL/Java (masses of non-C code was the
> main one) probably don't apply in these 2 cases.

I don't think it's the amount of non-C code; it's the amount of code
that no one understands. Plus, an argument *for* inclusion was build
farm coverage, which I understand will be solved in a different way,
applicable to all external modules. Another argument was buzzword
compliance, which doesn't apply to these two new candidates. So in
summary, while I have not seen any valid reason for these inclusions,
there continue to be some against it.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Joshua D. Drake wrote:
> PLRuby is written in C.

Specifically on the matter of PL/Ruby -- and if you're trying to be such
an advocate about it, you should at least spell it right -- I have
never seen the author particularly active within this community, so I
have my doubts whether the development processes will integrate well.
In fact, shouldn't the inclusion request come from the author in the
first place?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Peter Eisentraut wrote:
> Andrew Dunstan wrote:
>> But the reasons that applied to PL/Java (masses of non-C code was the
>> main one) probably don't apply in these 2 cases.
>
> I don't think it's the amount of non-C code; it's the amount of code
> that no one understands. Plus, an argument *for* inclusion was build
> farm coverage, which I understand will be solved in a different way,
> applicable to all external modules. Another argument was buzzword
> compliance, which doesn't apply to these two new candidates. So in
> summary, while I have not seen any valid reason for these inclusions,
> there continue to be some against it.

Ahh o.k. not to be argumentative but PHP is huge and RUby gets more then
it fair share of press and articles written about it now.

Alot of those *enterprises* that used to use Java are migrating to PHP
(why I really don't know but that isn't the point).

That being said, PLphp is currently a no-op and won't be able to be
considered for 8.2 due to portability issues. However PLruby is a valid
inclusion and would enhance our portfolio of pl languages nicely.

PLruby also has the benefit of not being repulsive to Perl or Python
programmers (where is many perl and python guys really don't like the
other ).

Sincerely,

Joshua D. Drake



>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Peter Eisentraut wrote:
> Joshua D. Drake wrote:
>> PLRuby is written in C.
>
> Specifically on the matter of PL/Ruby -- and if you're trying to be such
> an advocate about it, you should at least spell it right -- I have
> never seen the author particularly active within this community, so I
> have my doubts whether the development processes will integrate well.
> In fact, shouldn't the inclusion request come from the author in the
> first place?

That is a good point. However in this case, it was CMD that worked with
the Author to change the license, specifically for this case. I don't
think the author really had any intent of submitting it until we
approached him.

From a personal perspective, I do not care if we include PL/Ruby. I
don't use Ruby. I am a Python guy. However I know a lot of Ruby folk
that use PostgreSQL. This would be a good way to improve the native Ruby
support for PostgreSQL.

Sincerely,

Joshua D. Drake

>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut wrote:

>Andrew Dunstan wrote:
>
>
>>But the reasons that applied to PL/Java (masses of non-C code was the
>>main one) probably don't apply in these 2 cases.
>>
>>
>
>I don't think it's the amount of non-C code; it's the amount of code
>that no one understands. Plus, an argument *for* inclusion was build
>farm coverage, which I understand will be solved in a different way,
>applicable to all external modules. Another argument was buzzword
>compliance, which doesn't apply to these two new candidates. So in
>summary, while I have not seen any valid reason for these inclusions,
>there continue to be some against it.
>
>
>

Well, I am not making any promises right now about when buildfarm will
support external modules.

My current thinking goes something like this:

.. the config file will contain an extra stanza looking something like this:
addons => { <addonname> => { cvsrepo => "<repo locn>", module=>
"<modulename>" } ... }
.. addons will be checked out at the same time as the core, but into a
separate directory. We will check them for recent mods in the same way
as the core.
.. after we run "make installcheck" for the core we will run "make" for
each addon using the installed pgxs.
.. after we run "make installcheck" for contrib we will run "make
installcheck" for each addon.

(Question - do we restrict addons to those that will build using pgxs?)

Happily, most of the webapp is agnostic about what is reported on -
probably adding one db field containing the addon names for the build
would suffice.

There are some odd wrinkles. For instance, construction of the URLs for
changed files will be somewhat harder. For that reason I think I am
going to insist at least in the first instance that all addons must be
hosted on pgfoundry where we know perfectly well how to construct cvsweb
URLs.There will undoubtedly be more when I get down to it. And we might
need to ignore addons for builds on stable branches up to and including
8.2 - I don't know yet.

Now, if someone feels like taking those ideas and running with them in
the buildfarm client code they are welcome to drop me a line and I can
add them to the project as a developer. Otherwise it will have to wait
till I get around to it. That's likely to be some way well into the 8.3
development cycle at the earliest.

And lastly, if we are not going to include these in core, I repeat what
I said before: we need to undertake some *serious* evangelising to major
packagers to get them to build more than just the core among their
standard packages.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match