Skip site navigation (1) Skip section navigation (2)

Re: plPHP in core?

From: Joe Conway <mail(at)joeconway(dot)com>
To: Thomas Hallgren <thhal(at)mailblocks(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>,"Psql_General (E-mail)" <pgsql-general(at)postgresql(dot)org>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Filip Hrbek <filip(dot)hrbek(at)plz(dot)comstar(dot)cz>
Subject: Re: plPHP in core?
Date: 2005-04-02 19:24:05
Message-ID: 424EF155.5020308@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2005-04-02 19:24:27
Subject: Re: plPHP in core?
Previous:From: Marc G. FournierDate: 2005-04-02 19:20:48
Subject: Re: [HACKERS] plPHP in core?

pgsql-general by date

Next:From: Marc G. FournierDate: 2005-04-02 19:24:27
Subject: Re: plPHP in core?
Previous:From: Marc G. FournierDate: 2005-04-02 19:20:48
Subject: Re: [HACKERS] plPHP in core?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group