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

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> 
>>I'm not convinced that PLs are more tied to the core than say OpenFTS, 
>>and if we can't maintain that kind of thing externally, then this whole 
>>extension thing sounds like a failure to me.
> 
> 
> It's *possible* to do it.  Whether it's a net savings of effort is
> questionable.  For instance, I've had to hack plperl and plpgsql
> over the past couple days to support OUT parameters, and the only
> reason I didn't have to hack the other two standard PLs is that they
> are a few features shy of a load already.  I'm pretty sure pl/r and
> pl/java will need changes to support this feature too.  If they were in
> core CVS then I'd consider it part of my responsibility to fix 'em
> ... but they aren't, so it isn't my problem, so it falls on Joe and
> Thomas to get up to speed on what I've been doing and do likewise.
> Is that really a win?
> 
So far we've been able to keep up with PostgreSQL changes because a) the 
interfaces are after all pretty well defined, and b) there is always a 
long enough delay between changes of the interfaces and their official 
release to make it possible for us to catch up. Cumbersome sure, but 
still not my primary concern. There's a couple of other reasons why it's 
bad to be an "outsider".

a) If skilled core developers from time to time stumbled on compilation 
errors in PL/Java due to changes made in the backend, then I believe 
that this would result in some level of code review and perhaps lots of 
good criticism and ideas of improvement.

b) I've been forced to do pull some tricks in PL/Java to work around 
things that I consider lacking in the interfaces. Having PL/Java in core 
would make it possible to work together more tightly in order to find 
good solutions/API's that can benefit all PL's.

c) PL/Java would become (optional?) part of the build and the regression 
tests. It would be great to get early warnings when things change that 
break PL/Java.

d) Bringing PL/Java into core will force a consistent documentation and, 
I imagine, a chapter of it's own in the main docs. I'm happy to write 
most of it but English is not my native language. Whatever I put into 
print will always benefit from a review.

e) The article http://www.powerpostgresql.com/5_types describes another 
serious issue pretty well. While it's easy for an organization to become 
dependent on the "Community" based PostgreSQL, it's much more difficult 
to make such a decision with the "Solo" based PL/Java.

In essence, I'm all for bringing PL/Java into core. While doing so I 
think it's imperative to maintain good API's between modules and 
backend. Bringing the PL's into core must be done while retaining good 
separation of concern. The extension mechanism is a good thing. It 
should be improved regardless where PL's end up.

> The point here is really that we keep finding reasons to, if not
> flat-out change the interface to PLs, at least expand their
> responsibilities.  Not to push it too hard, but we still have only
> one PL with a validator procedure, which IIRC was your own addition
> to that API.  How come they don't all have validators?
> 
For PL/Java, the answer is that we just haven't had the time to 
implement it. It should be done of course.

Regards,
Thomas Hallgren