Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-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 

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?




In response to


pgsql-hackers by date

Next:From: WesDate: 2005-04-04 15:38:56
Subject: Re: Vacuum time degrading
Previous:From: Christopher Kings-LynneDate: 2005-04-04 15:20:25
Subject: Unicode problems on IRC

pgsql-general by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group