Bruce Momjian <br...@momjian.us> writes:
> On Tue, May 29, 2012 at 02:38:03PM -0400, Tom Lane wrote:
>> Well, it'd eliminate the kluges for plpython, as well as possibly fixing
>> Andrew's JSON backport issue, and going forward there are going to be
>> more things like that. So I think it's something to pursue, but it's
>> not going to be a simple change unfortunately.
> I am confused how they fix the plpython issue (mapping plpython.so to
> plpython2.so). Is there an extension for these languages or is it just
> pg_pltemplate? Which extensions have config files?
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
