Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables - Mailing list pgsql-hackers

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Dimitri Fontaine wrote:
>> It seems harder to come up with a general purpose syntax to support the
>> feature in case of toast tables, though.

> There's already general purpose syntax for relation options which can be
> used to get options that do not ultimately end up in
> pg_class.reloptions.  An existing example is WITH (oids).  One such
> option could be used here.

That would cover the problem for OIDs needed during CREATE TABLE, but
what about types and enum values?

The half-formed idea I had was a set of GUC variables:

set next_pg_class_oid = 12345;
set next_pg_type_oid = 12346;
set next_toast_table_oid = ...
set next_toast_index_oid = ...

and finally it could do CREATE TABLE.  CREATE TYPE would only need
next_pg_type_oid (except for a composite type).

Enum values wouldn't work too well this way, unless we were willing to
have a GUC that took a list of OIDs.  I thought about having binary
upgrade mode build up the enum list one entry at a time, by adding
a command like
ALTER TYPE enum_type ADD VALUE 'label' WITH OID oid

which would also have some use for modifying enums on the fly.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: Filtering dictionaries support and unaccent dictionary
Next
From: Andrew Dunstan
Date:
Subject: Re: Re: [Pg-migrator-general] Composite types break pg_migratedtables