Tom Lane wrote:
> But it's exactly the same hole the user would create by manually
> saying CREATE TRUSTED LANGUAGE in error. I don't think that's a
> reasonable argument against the template idea --- it just says that
> you have to be aware of what you're doing.
>
> (An appropriate solution, in my mind, would be to drop the trusted
> call handler from the shared library if it's built with gcj --- then
> there's really no possibility of doing the wrong thing.)
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. This is the kind of freedom of choice that the current
situation allows. Now the template solution will buy nothing here,
because there has never been a release of PL/Java that (a) used a
hard-coded shared library path, or (b) was ambiguous about its
installation schema in the first place. And the validator upgrade
issue will also not be solved unless there is a major synchronization
effort between the PostgreSQL upstream, the PL/Java upstream, the
PostgreSQL packager, and the PL/Java packager (4 different parties)
(and in worse cases: the GCC packagers, etc.). In other words, it is
not possible and could only be solved effectively by putting PL/Java in
the core both upstream and downstream.
I think you are assuming all the way through this discussion that a
PostgreSQL upgrade will also entail an upgrade of all procedural
languages. People are putting dummy validator functions into their
code right now, but (1) will they also release that new version at the
same time as PostgreSQL 8.1 comes out?, and (2) will users be willing
to upgrade at the same time? Point 1 is questionable at best, and
point 2 is completely out of the question, not only because I've seen
too many PL releases just plain break, but simply because people may
want to upgrade one thing at a time. Again, we could work around both
of these points by putting the PL in question into the core, in which
case I am willing to support the template idea, but for languages out
of the core I don't think the implicitly required synchronization
efforts have been taking into account.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
