Josh Berkus <j...@agliodbs.com> writes:
>> The disadvantage of this scheme is that if you repeatedly insert entries
>> in the "same place" in the sort order, you halve the available range
>> each time, so you'd run out of room after order-of-fifty halvings.
> This is not a real issue. If anyone is using an ENUM with 1000 values
> in it, they're doing it wrong. However, we'd have to present an
> intelligible error message in that case.
You wouldn't need 1000 values to get into trouble. If you did
CREATE TYPE e AS ENUM ('a', 'b');
ALTER TYPE e ADD 'c1' BEFORE 'b';
ALTER TYPE e ADD 'c2' BEFORE 'b';
ALTER TYPE e ADD 'c3' BEFORE 'b';
ALTER TYPE e ADD 'c4' BEFORE 'b';
...
you'd hit the failure somewhere around c50, assuming IEEE-style floats.
I think an "intelligible error message" wouldn't be hard; it'd say
something like "no more room to insert another enum label between enum
labels c49 and b".
> The float method would also have a couple other issues:
> (1) larger value for the enum order, so more RAM. Do we care?
The in-memory representation wouldn't be any bigger, because we don't
actually need to keep the enumorder values in the cache entries.
pg_enum rows would get wider, but not materially so considering they
already contain a 64-byte name column.
> (2) would need to create a view which hid the floats from admins who
> just want to look at the enum ordering.
Why? We weren't going to hide the enumorder values before, why would we
do it with this?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
