From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Jeff <threshar(at)threshar(dot)is-a-geek(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Date: | 2009-08-06 14:28:29 |
Message-ID: | 3462.1249568909@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-08-06 14:32:46 | Re: Re: [Pg-migrator-general] Composite types break pg_migratedtables |
Previous Message | Teodor Sigaev | 2009-08-06 14:27:10 | Re: Filtering dictionaries support and unaccent dictionary |