Re: pg_upgrade libraries check - Mailing list pgsql-hackers

On Tue, May 29, 2012 at 04:10:41PM -0400, Tom Lane wrote:
> Hmmm ... that is a good point; right now, there are probably still an
> awful lot of installations that have PL languages installed "bare"
> rather than wrapped in an extension, including all the ones where the
> plpython library has the old name.  So a fix that only considers
> extensions doesn't get you out of the plpython problem.
> 
> (Eventually I would like to see "CREATE LANGUAGE foo" with no parameters
> redefined as doing "CREATE EXTENSION foo", and doing away with
> pg_pltemplate; but it didn't get done for 9.2.)
> 
> Actually, though, I don't see why pg_upgrade couldn't treat PL
> languages, even bare ones, the same way I'm proposing for extensions.
> Right now, it's already the case AFAICS that pg_dump --binary-upgrade
> does not dump PL support functions for PLs listed in pg_pltemplate;
> it just emits the CREATE LANGUAGE command and nothing else.  This being
> the case, it's simply wrong for pg_upgrade to be checking shlib names
> for the old support functions, because that has got exactly nothing
> to do with whether the CREATE LANGUAGE command will succeed in the new
> installation.  There are at least two ways you could check that
> condition without assuming that the shlib name has stayed the same:
> 
> 1. Look for an extension control file for the language name in the new
> installation; if present, assume the proper shlib is installed too.
> 
> 2. Look at the pg_pltemplate entries for the language in the new
> database and see if they point to a shlib that exists.
> 
> I'd vote for #1 on the grounds that it's simpler and won't break when
> we remove pg_pltemplate.  It does assume that packagers of third-party
> PLs have gotten off their duffs and extension-ified their languages.
> I would think that would have been a pretty popular thing to do, though,
> since it so greatly reduces the installation complexity for a language
> not known to pg_pltemplate.

Uh, there is a pg_upgrade C comment on this, so we did discuss it at
some point;  see second paragraph:
        *  In Postgres 9.0, Python 3 support was added, and to do that, a        *  plpython2u language was created
withlibrary name plpython2.so        *  as a symbolic link to plpython.so.  In Postgres 9.1, only the        *
plpython2.solibrary was created, and both plpythonu and        *  plpython2u pointing to it.  For this reason, any
referenceto        *  library name "plpython" in an old PG <= 9.1 cluster must look        *  for "plpython2" in the
newcluster. *        *  For this case, we could check pg_pltemplate, but that only works        *  for languages, and
doesnot help with function shared objects,        *  so we just do a general fix.
 

The bottom line is that already needed function shared objects checking,
so we just wrapped languages into that as well.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +