Re: pg_upgrade libraries check - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade libraries check
Date
Msg-id 20120529194043.GI20260@momjian.us
Whole thread Raw
In response to Re: pg_upgrade libraries check  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgrade libraries check
List pgsql-hackers
On Tue, May 29, 2012 at 02:38:03PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >>> In fact, can we identify right now if a function is used only by an
> >>> extension?
> 
> >> ITYM is the function defined by an extension, and the answer to that is
> >> "look in pg_depend".
> 
> > So is this something I should be exploring, or not worth it at this
> > time?  It would allow changing the names of extension shared object
> > files, but right now I don't know anyone doing that, so I am not sure of
> > the value of the change.
> 
> 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?

> As Robert pointed out, we have to be able to preserve OIDs for at least
> the types exported by an extension.  So that seems to mean that we need
> some mechanism intermediate between "just run the new extension script"
> and the current "physically duplicate the extension's contents"
> approach.  I'm not real sure what that should look like.  As a straw
> man, I could imagine making pg_dump --binary-upgrade produce something
> like
> 
>     CREATE EXTENSION hstore
>         WITH OIDS (TYPE hstore = 12345, TYPE hstore[] = 12346);
> 
> and then having code in CREATE EXTENSION that does the equivalent of the
> OID-forcing hacks when we're about to create an object that matches
> something in the WITH OIDS list.  Or maybe it'd be better to leave the
> SQL command alone, and generalize the existing OID-forcing hooks so that
> we can pre-set a list of names to force OIDs for, and then everything
> can happen behind the back of CREATE EXTENSION.

Yes, we have used those hooks before, and they are pretty clean.  I
wonder if the OID preservation designation has to be _in_ the extension
script, but I am unclear how that would be passed to pg_upgrade or
pg_dumpall.  As you said, it is pretty complex, and I am seeing that
now.

--  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: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.
Next
From: Tom Lane
Date:
Subject: Re: GiST buffering build, bug in levelStep calculation