Re: WIP: extensible enums

Josh Berkus <josh(at)agliodbs(dot)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