Re: plPHP in core? - Mailing list pgsql-general
From | Joe Conway |
---|---|
Subject | Re: plPHP in core? |
Date | |
Msg-id | 424EF155.5020308@joeconway.com Whole thread Raw |
In response to | Re: plPHP in core? (Thomas Hallgren <thhal@mailblocks.com>) |
List | pgsql-general |
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
pgsql-general by date: