On 13-Jul-06, at 1:02 PM, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I also cannot maintain Java, but we could do something like we do
with
WIN32, where outside folks submit patches to fix problems.
However, a win32 failure breaks only the win32 buildfarm members ...
Basically my point here is that I see no synergy from having PL/Java
(or PL/J for that matter) in core. They can't share the same
configure
or build support as the rest of the code; the core developers don't
feel
qualified to maintain them; what's left?
The argument in favor boils down to one and only one thing: bundling
PL/Java will improve the visibility of PL/Java to people who won't go
looking for it. That's fine, but ultimately that's a packaging
argument
not a development argument. The people who think PL/Java is an
essential checklist item undoubtedly also think JDBC is an essential
checklist item, but I'm not seeing any groundswell of support for
putting JDBC back into core.
Well, if this discussion ends up in a java project getting into core
then there would be no reason whatsoever not to include JDBC. It's
certainly more germane to the project than the java pl's
Instead we expect packagers (like the RPM
set) to make JDBC available alongside the core postgres packages.
That's how PL/Java ought to be handled, too, IMHO.
In my own experience dealing with the Red Hat RPMs, it got a whole lot
easier to package JDBC correctly once it wasn't mis-bundled into a
basically non-Java source tarball, so I think that the packagers will
also find that keeping it separate makes their lives easier.
regards, tom lane
Regards,
Dave
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
