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 tem****ary
enum, rewriting the tables one by one each on its own transaction, and
finish by dropping the original enum and renaming the tem****ary 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@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
