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/ ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
