Re: WIP: extensible enums

Josh Berkus <josh@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