Re: Fix corner case for binary upgrade: extension functions in pg_catalog.

Started by Dimitri Fontainealmost 15 years ago3 messages
#1Dimitri Fontaine
dimitri@2ndQuadrant.fr

Tom Lane <post@gwene.org> writes:

Fix corner case for binary upgrade: extension functions in pg_catalog.

Do we only want to care about functions here? What about the following?

CREATE EXTENSION hstore WITH SCHEMA pg_catalog;

When not doing binary upgrade, this will issue the right pg_dump
command, but it seems to me that you're saying that binary upgrades in
such a case would be a problem still.

Normally, pg_dump summarily excludes functions in pg_catalog from
consideration. However, some extensions may create functions in pg_catalog
(adminpack already does that, and extensions for procedural languages will
likely do it too). In binary-upgrade mode, we have to dump such functions,
or the extension will be incomplete after upgrading. Per experimentation
with adminpack.

* [DBH] src/bin/pg_dump/pg_dump.c

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Dimitri Fontaine (#1)

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:

Tom Lane <post@gwene.org> writes:

Fix corner case for binary upgrade: extension functions in pg_catalog.

Do we only want to care about functions here?

Yes. Functions/aggregates are the only object type where pg_dump tries
to suppress fetching any information at all about system-owned objects;
it's the only case where there's so many system objects as to be worth
the trouble.

regards, tom lane

#3Dimitri Fontaine
dimitri@2ndQuadrant.fr
In reply to: Tom Lane (#2)

Tom Lane <tgl@sss.pgh.pa.us> writes:

Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:

Tom Lane <post@gwene.org> writes:

Fix corner case for binary upgrade: extension functions in pg_catalog.

Do we only want to care about functions here?

Yes. Functions/aggregates are the only object type where pg_dump tries
to suppress fetching any information at all about system-owned objects;
it's the only case where there's so many system objects as to be worth
the trouble.

Makes for a nice localised fix. Thanks for explaining (again) :)

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support