On Tue, May 29, 2012 at 02:38:03PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote: > >> Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers