Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables
От | Tom Lane |
---|---|
Тема | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Дата | |
Msg-id | 3462.1249568909@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Re: [Pg-migrator-general] Composite types break pg_migrated
tables
Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Список | 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 по дате отправления: