Tom Lane wrote:
> 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.
There is a standard for the SQL integration of a "java" language, and I
don't see why there can't be multiple implementations of that same
specification. It in fact appears that there are. Of course we would
not want the programming interfaces to differ, but they don't have to.
> 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.
Hmm, Thomas Hallgren sent in a template using "java" as name and you
answered "OK", so we're already there if it's already committed.
> 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.
There is no hope of that, but a mere recompilation does not change the
validator or the schema or any other property that may be under
consideration. The current code will force a *version* upgrade of all
PLs with every PostgreSQL upgrade. I need to download new code and
deal with it. That is currently not required. And considering the
general breakage of PLs out there, I don't think it's acceptable to
require it. What if the new PL/R also requires a new R? What if the
new R requires a new GCC? We don't know that, we can't control that,
we should not interfere in that. I'm not making this up; these
problems are real (although not necessarily in PL/R).
--
Peter Eisentraut
http://developer.postgresql.org/~petere/