Re: pg_upgrade libraries check

On Tue, May 29, 2012 at 02:38:03PM -0400, Tom Lane wrote:
> 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.

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +