Re: PL/php in pg_pltemplate

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.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/