Re: [GENERAL] plPHP in core? - Mailing list pgsql-hackers

Marc G. Fournier wrote:
> On Sat, 2 Apr 2005, Dave Cramer wrote:
> 
>> pl-j ( the other java procedural language ) is definately interested 
>> in being in core.
> 
So your objectives has changed then? As I recall it, Laszlo thought it 
important to keep some level of database independence with PL/J and 
didn't really care to become part of core, hence numerous dependencies 
to remote components, use of maven instead of make, etc.

Looking at the feasibility of a PL/Java + PL/J merge, I found the way 
PL/J is build up a major obstacle.

> Yet another good reason *not* to be including PLs ... similar to why we 
> moved libpq++ out of core ... I may be wrong, but I doubt that pl-j has 
> the same feature set as pl-java, or vs versa ... so, what do we do? each 
> time someone argues for a better widget, we swap out the old and include 
> the new?  there is no guarantee that plPHP will be the only PHP based PL 
> out there, any more then the other PLs, or language libraries ...
> 
Not sure I understand this point. To state that PostgreSQL ships with 
plPHP would be a very powerful statement. To me that's in the same 
ballpark as saying PostgreSQL now has a autovacuum feature. Sure, 
another autovacuum feature might be created somewhere. If it is, and if 
it is superior to what you have, and if the people behind it wants it 
submitted into core, what would you do?

If you bring plPHP into core you will make a serious statement. To most 
people it will mean "there's no point in writing another". After that, a 
new external PHP might still be built for two reasons:

a) The core version is seriously neglected.
b) A completely new take on the plPHP (plPHPng :-) ) is underway.

In both cases, the result is likely to become something that you want to 
use as a replacement. You can stipulate the terms for such a replacement 
to take place (such as backward compatibility). So what's the problem?

> *If* something *requires* the physical postgresql source code to be 
> available (not just the isntalled headers/libraries), like libpq does, 
> then it makes sense to be part of the core distribution ...>
Personally, I think that good separation of concern is utterly important 
*even if* a module should be part of a core. PL/Java used to require 
source to compile but that's no longer true (thanks to pgxs). Following 
your line of reasoning my chances to get PL/Java into core would improve 
if I went back to the old way of compiling.

On the flip side, improving the separation of concern between libpq and 
the backend so that other protocols could benefit would perhaps be a 
good thing. It should not however imply that libpq then gets expelled 
from core, should it?

> but, IMHO, 
> the core distribution shouldn't be 'the means to validation' of an 
> interface, since it unfairly negates work that someone else might be 
> working on (ie. in this case, Dave's pl-j alternative to pl-java) ...
> 
Very important point that should not be restricted to a pl-j versus 
pl-java discussion. It's valid to pl's in general. The fact that 
PostgreSQL ships with some PL's is suppressing others (I'm thinking 
again of the Community versus Solo type projects) and suggests that you 
have an implicit validation process in place. Perhaps you should make 
that process explicit and more formal?

Regards,
Thomas Hallgren