Re: [GENERAL] plPHP in core? - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: [GENERAL] plPHP in core? |
Date | |
Msg-id | 42515EEA.7020006@dunslane.net Whole thread Raw |
In response to | Re: [GENERAL] plPHP in core? (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [GENERAL] plPHP in core?
|
List | pgsql-hackers |
Tom Lane wrote: >"Marc G. Fournier" <scrappy@postgresql.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 > >
pgsql-hackers by date: