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