Re: Attention PL authors: want to be listed in template table?

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