On 10/23/2010 07:12 PM, Tom Lane wrote:
Andrew Dunstan<and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
