Peter Eisentraut <peter_e@gmx.net> writes:
> The case in reality is this: First of all, the language name "java" is
> fixed by the SQL standard, so we ought to allow alternative
> implementations to use that name. I'm not sure what kind of interface
> the PL/J people are working on, but if they also lay claim to the name
> "java", then we have a problem. Second, Java is not, in fact, always
> Java, so different quality variants of the same implementations exist.
> The Debian package of pljava is compiled using gcj, but it is also
> planned to provide an alternative version that is compiled using the
> Sun JDK. That way, users can trade off quality/features vs. licensing
> freedom.
Are you seriously suggesting that it's a good idea for the single
language name "java" to mean different things at different
installations? I can't believe that that wouldn't lead to chaos.
In any case, "java" has not been put forward as one of the template
entries, and as long as we don't accept a template for it, we have
not made the situation any worse.
> I think you are assuming all the way through this discussion that a
> PostgreSQL upgrade will also entail an upgrade of all procedural
> languages.
Yes, I am assuming that, and I challenge you to supply examples of PLs
that won't require at least a recompile before there's any hope of their
working on 8.1. In a quick look through the CVS logs, I note that
heap_openr/index_openr are gone, the representation of pg_proc entries
is quite a bit different than it was in 8.0, and there are incompatible
changes in the APIs of spi.c and dynahash.c. The pg_proc changes in
particular practically guarantee a need for a source-code update.
regards, tom lane