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. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
