Skip site navigation (1) Skip section navigation (2)

Re: PL/php in pg_pltemplate

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PL/php in pg_pltemplate
Date: 2005-11-25 16:37:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 

Peter Eisentraut

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-11-25 17:02:04
Subject: Re: [HACKERS] Should libedit be preferred to libreadline?
Previous:From: Olivier ThauvinDate: 2005-11-25 15:59:27
Subject: Re: gprof SELECT COUNT(*) results

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group