Alvaro Herrera wrote:
> Well, it's one step less for installing the language. Users just
> install the library and issue the appropiate CREATE LANGUAGE call; no
> need to mess with specifying the handler/validator function name.
> (Which is not a very big deal, granted, but it's precisely the reason
> why pg_pltemplate was invented.)
No, the actual reason why pg_pltemplate was invented is so that during a
major version upgrade, the CREATE LANGUAGE statement contained in the
dump would automatically be readjusted internally to pick up whatever
new features the language would provide in the new major version (e.g.,
a new validator function). The applicability of that feature, in my
heavily contested opinion mind you, to non-core languages is reduced by
two facts:
1. A major version upgrade does not entail an upgrade of the respective
language handler, both because of mere software availability and
because of a possible upgrade-only-one-thing-at-a-time policy.
2. The PostgreSQL backend is not in an authoritative position to know
what kind of features a certain external language handler really
provides (think development versions, for example).
The counterargument has been that a PostgreSQL major version upgrade
would typically require a version upgrade of all language handlers. In
my experience of maintaining and observing the maintenance of binary
packages for PostgreSQL and languages, this is decidedly false, at
least in the general case.
The PL/PHP package is a pretty obvious case where things can go wrong,
especially if you have tight dependencies. You may decide that the
next version of PL/PHP will require PHP 5.2.0. You put that in the
pltemplate for PostgreSQL 8.2. When someone packages that for some
Linux distribution, that distribution may not have PHP 5.2.0 ready
because of the insanse dependency chains that PHP brings in. So they
have to stick to the old PL/PHP in their distribution, but PostgreSQL
8.2 does not know that. So either PL/PHP is broken or they have to
patch the source code (well, the system catalogs) of PostgreSQL. You
can see, the more languages we bring in this way, the farther the
dependency chaos reaches. And I don't think that's worth saving some
typing...
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
