Dimitri Fontaine wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > In any case that would ratchet the priority of ALTER EXTENSION UPGRADE
> > back up to a must-have-for-9.1, since pg_upgrade would then leave you
> > with a non-upgraded extension.
> >
> > Now what?
>
> What would be the problem with pg_upgrade acting the same as a
> dump&reload cycle as far as extensions are concerned? After all those
> can be considered as part of the schema, not part of the data, and the
> system catalogs are upgraded by the tool.
>
> It would then only break user objects that depend on the extension's
> objects OIDs, but that would be the same if they instead recorded the
> OID of catalog entries, right?
>
> So a valid answer for me would be that when you pg_upgrade, the
> extensions are installed again from their scripts. If you want to go
> further than that, you can insist on having the same version of the
> extension on both sides, but that would defeat the purpose of the tool
> somehow. After all you asked for an upgrade?
The C comment in pg_upgrade.c explains the problem:
* We control all assignments of pg_type.oid because these oids are stored* in user composite type values.
(Wow, I am glad I recorded all these details.)
The problem is that pg_dump --binary-upgrade knows to call
binary_upgrade.set_next_pg_type_oid() before CREATE TYPE (you can test
it yourself to see), and I am afraid we will need to do something like
that in the extension code, perhaps by supporting a --binary-upgrade
flag like we do for pg_dump. That seems to be the cleanest approach.
A worse approach would be to somehow pass oids to pg_upgrade and have it
renumber things but that seems hopelessly error-prone.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
