Re: plPHP in core?

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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