Re: [GENERAL] plPHP in core?

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