Alvaro Herrera wrote:
Andrew Dunstan escribió:
Tom Dunstan wrote:
So two alternative proposals, both with a 2 byte "enum id" and a 2 byte "value":
1 - We space the values out as evenly as we can across the 65000ish
range and allow people to delete, insert and append, but not reorder.
If they do the above gratuitously we might have to do a rewrite, but
they'll have to get fairly busy to do it. Rewrite would be required
for reorderings.
Or else we just error out in such cases. As Tom Lane suggests, rewriting
has some nasty deadlock possibilities.
You always have the option of creating a new enum type and moving each
affected column to that type.
Another alternative would be internally creating a different temporary
enum, rewriting the tables one by one each on its own transaction, and
finish by dropping the original enum and renaming the temporary one.
This solves the deadlock problem.
What happens when someone tries to join two of the tables, one that has
been converted and one that hasn't? You might not have deadlock, but you
won't have type integrity either, ISTM.
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
