Re: [HACKERS] plPHP in core?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Psql_General (E-mail)" <pgsql-general(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] plPHP in core?
Date: 2005-04-04 15:36:10
Message-ID: 42515EEA.7020006@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tom Lane wrote:

>"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>
>
>>On Fri, 1 Apr 2005, Joshua D. Drake wrote:
>>
>>
>>>Are we interested in having plPHP in core?
>>>
>>>
>
>
>
>>Is there a reason why it can no longer operate as a standalone language
>>out of pgfoundry, like pl/java and pl/perl?
>>
>>

I have said this before. Let me say it again and please take note. I did
not start the plperlng project on pgfoundry as an alternative to the
core plperl. It is a developers sandbox, and it was always the intention
to feed the work back to the core, as indeed we did for the 8.0 release.
Frankly, if I had thought that there would be so much wilful
misunderstanding of the intention I would not have done it. So please
stop with this assertion that plperl runs from pgfoundry.

I am really at a loss to understand thie push to get PLs out of the
core. Whose interest do you think it will serve? We just advertised the
upgrade to plperl as a major selling point of the 8.0 release. The
"someone might do it differently or better" argument is a cop-out. If
you're in the management group your responsibility is to make sensible
choices.

Lots of software acquires standard packages over time. Example: perl,
which has an extremely well publicised and well-known extension system
(CPAN) that has had for years a high resolution timer extension package
available. From the 5.8 release that package has become part of the
standard distribution. That doesn't stop anyone from developing a better
or alternative hires timer.

If we had a very much larger postgres development community then it
might make sense to foster some diversity among PL implementations. We
don't, so it doesn't, IMNSHO.

>
>PLs are sufficiently tightly tied to the core that it's probably
>easier to maintain them as part of our core CVS than otherwise.
>(Ask Joe Conway about PL/R. Thomas Hallgren is probably not that
>happy about maintaining pl/java out of core, either. And pl/perl
>*is* in core.)
>
>

And we need the core support. I appreciate having the support and help
of Tom, Joe, Bruce and others. I have little doubt Joshua Drake feels
the same way.

>I'm thinking that a pl/PHP is much more interesting for the long term
>than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but
>I see that many people are not so enlightened). Barring any licensing
>problems I think this is something to pursue.
>
>
>

Yes, I regard it as an abomination unto man and god, but others want it.
:-) If there are no license or build issues I'm in favor. Quite apart
from anything else it might help grab some market share from all those
apps built on php+mysql

One last thing: one of the enhancements in the wind for buildfarm is to
run the PL tests. This will *only* be done for PLs that are in the core
- I am not going to get into buildfarm having to run cvs update against
more than one source. So if you want that to happen, keep the PLs where
they are (and take on pl/php if possible). I'd also love to have pl/ruby
- is that another one that is inhibited by license issues?

cheers

andrew

>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-04-04 15:36:24 Re: invalid input syntax for type bytea
Previous Message Chris Kratz 2005-04-04 15:28:00 UNICODE encoding and jdbc related issues

Browse pgsql-hackers by date

  From Date Subject
Next Message Wes 2005-04-04 15:38:56 Re: Vacuum time degrading
Previous Message Christopher Kings-Lynne 2005-04-04 15:20:25 Unicode problems on IRC