Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables

Tom Lane wrote:
> 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.
>
>
>   


It's going to be fairly grotty whatever we do. I'm worried a bit that 
we'll be providing some footguns, but I guess we'll just need to hold 
our noses and do whatever it takes.

cheers

andrew