Tom Lane wrote:
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".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?
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.
For PL/Java, the answer is that we just haven't had the time to implement it. It should be done of course.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?
Agreed. Time has been hard for me to come by lately :(
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
