Re: pg_upgrade libraries check

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)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.

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.

regards, tom lane