Re: WIP: extensible enums

On 10/23/2010 07:12 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> Latest patch attached.
> I've been working through this patch.

Cool.

[snip: reallocating enum sortorder on existing values has race 
conditions. Suggestion to use a float8 instead and add new value half 
way between neighbours, so no reassignment is necessary]

> 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.
> The values would eventually differ by only one unit in the last place,
> so it'd not be possible to insert another value that would still be
> distinguishable in the sort order.  Is that an acceptable restriction?
> (If you did run into this, you could manually reassign enumsortorder
> values to get out of it, without having to dump-and-reload; but you'd
> have to beware of the same race condition as above.)  Of course adding
> new values at the start or end of the enum's list wouldn't have that
> restriction.

Well, it's a tiny bit like my initial proposal for enum Oid ranges with 
gaps, but with a level of indirection :-)

Seriously, I think it might be OK. Could we provide some safe way of 
resetting the sortorder values? Or even a not-entirely-safe 
superuser-only function might be useful. Binary upgrade could probably 
call it safely, for example.

We've sure expended quite a lot of neurons on this feature :-)

cheers

andrew