Re: PL/php in pg_pltemplate

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > 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.
>
> Really? I'd argue the opposite. See also the recent proposal to
> *force* recompilation of all loadable shared libraries for every
> major PG version, by means of embedding a version number in them.

That's a recompilation of the *same* version, not an upgrade of the
version of the PL.

If you upgrade from PostgreSQL 8.0 to 8.1 you effectively also upgrade
from "PL/pgSQL 8.0" to "PL/pgSQL 8.1". That's why we can and should
and do alter the installation parameters of that language at the same
time. But you don't necessarily upgrade from PL/foo 0.77 to PL/foo
0.78 at that time (instead you just recompile 0.77), which is why we
cannot really randomly include information on PL/foo in pltemplate
unless we make very particular arrangements with that development team,
which I don't see being done in any proposed 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.
>
> Hm? Where in pltemplate is there any knowledge of PHP versions?

pltemplate would more or less contain a hidden versioned dependency on
the external language. (pltemplate says, "The last known version of
PL/foo at the time of release supports these features." and you need to
use at least that version or the language installation might be
broken.) So we'd pull in a versioned dependency on PL/PHP, which might
have a versioned dependency on PHP (which might have a versioned
dependency on libssl, which is incompatible with the one used by
PostgreSQL, or whatever other weird case you want to imagine).

--
Peter Eisentraut
http://developer.postgresql.org/~petere/