Re: plPHP in core?

Thomas Hallgren wrote:
> Tom Lane wrote:

>> 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".

This has also been my experience. Every Postgres development cycle has
seen a half dozen or so backend changes that break PL/R. It usually
doesn't take too long to respond to the changes though.

> a) If skilled core developers from time to time stumbled on compilation
> b) I've been forced to do pull some tricks in PL/Java to work around
> c) PL/Java would become (optional?) part of the build and the regression
> d) Bringing PL/Java into core will force a consistent documentation and,

Agreed.

> 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.

This one is particularly important. I'm currently responsible for a
commercial project at work that sits on the shoulders of a good deal of
open source software. We've specifically needed to either avoid
components with single or a small number of maintainers, or make a
conscious decision to accept permanent responsibility to maintain the
code should the "Solo" disappear (and dedicate enough resource to become
comfortable with that code). Like it or not, I think everything
relegated to pgfoundry suffers from this to some degree. There is no
doubt in my mind that both PL/R and PL/Java would get much wider use
(and therefore wider testing and code review) if they were packaged with
the core Postgres distribution.

>> 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.

Agreed. Time has been hard for me to come by lately :(

Joe