Re: PL/php in pg_pltemplate - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PL/php in pg_pltemplate
Date
Msg-id 23425.1132938864@sss.pgh.pa.us
Whole thread Raw
In response to Re: PL/php in pg_pltemplate  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: PL/php in pg_pltemplate  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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.
If you think that would be a bad idea you'd better weigh in on that
thread pretty soon ...

> 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?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Should libedit be preferred to libreadline?
Next
From: Bruce Momjian
Date:
Subject: Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept