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".Peter Eisentraut <[EMAIL PROTECTED]> 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?
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.
For PL/Java, the answer is that we just haven't had the time to implement it. It should be done of course.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?
Regards, Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
