Re: pg_upgrade libraries check - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade libraries check
Date
Msg-id 20120529214800.GK20260@momjian.us
Whole thread Raw
In response to Re: pg_upgrade libraries check  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 29, 2012 at 05:35:18PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > The bottom line is that already needed function shared objects checking,
> > so we just wrapped languages into that as well.
> 
> Well, that'd be fine if it actually *worked*, but as per this
> discussion, it doesn't work; you have to kluge around the fact that
> the shared library name changed.  I'm suggesting that pg_upgrade needs
> to be revised to treat this stuff at a higher level.  Yeah, you need to
> look at shared library names for bare C functions, but we should be
> getting away from that wherever there is a higher-level construct such
> as an extension or PL.

Well, we have three problems.  One is the JSON problem that Andrew wants
skipped, there is the plpython rename which we adjust in the check, and
then there is the plpython support function that is in the public
schema, which I am working on a patch to throw a meaningful error.

The only one that actually is setup for a rename is the second one.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgrade libraries check
Next
From: Tom Lane
Date:
Subject: Re: Re: [BUGS] 9.2beta1 regression: pg_restore --data-only does not set sequence values any more