Bruce Momjian <bruce@momjian.us> 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. 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
