Peter Eisentraut <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq