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