On Thu, Jul 13, 2006 at 11:03:27AM -0400, Tom Lane wrote: > The only argument I find interesting for including the PLs in core > (which has zilch to do with how any particular packager ships them) > is that it's easier to do maintenance that way: if we make a change in > an API that affects the PLs, we can change the PLs at the same time.
> However, that argument only holds water if the core developers are > able/willing to make the corresponding changes. And in that light, > the fact that PL/Java includes a huge whack of non-C code is very > significant. *I* won't take responsibility for fixing PL/Java when > I break it, because I don't know Java well enough. I don't know what > other people who do core development feel about that --- but I dislike > the idea that when someone changes such an API, the buildfarm will go > all red because there's only one person with the ability to fix PL/Java. Tom: Currently, the PL implementations combine both language-specific glue and language-specific abstractions together. In light of your comments below, and the opinion I expressed in my previous response, I find myself wondering whether this architecture is contributing to the problem. Would it make sense for this architecture to be split? My thinking is that much of the code in the Perl, TCL, Java, ... PL implementations is related to language-specific abstractions and documentation, and does not need to be bundled with the core, nor does it need to be tested as a part of the core. For example, I imagine that many of the lines in PL/Java could be distributed as a single hardware-independent .jar file separate from the core, if the core exposed the required API to Java. Where this could go, is that the core developers would only be responsible for ensuring that the backend API functions as documented, without needing to understand how these functions are exposed to the user. You agree to maintain Java interfaces to the C functions. No more, no less. If somebody else wants to build complicated abstractions on top, or wants to provide thousands of pages of documentation - this is their choice, but would be distributed separate from the core, but would be simple to plug in. Am I just spitting crazy talk, or is this making sense? Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq