Tom Lane wrote:
Alvaro Herrera <alvhe...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
