|From:||ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=)|
|To:||Matthias Kurz <m(dot)kurz(at)irregular(dot)at>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: Alter or rename enum value|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Matthias Kurz <m(dot)kurz(at)irregular(dot)at> writes:
[altering and dropping enum values]
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>> > On 03/09/2016 11:07 AM, Tom Lane wrote:
>>> >> I have a vague recollection that we discussed this at the time the enum
>>> >> stuff went in, and there are concurrency issues? Don't recall details
>>> >> though.
>>> > Rings a vague bell, but should it be any worse than adding new labels?
>>> I think what I was recalling is the hazards discussed in the comments for
>>> RenumberEnumType. However, the problem there is that a backend could make
>>> inconsistent ordering decisions due to seeing two different pg_enum rows
>>> under different snapshots. Updating a single row to change its name
>>> doesn't seem to have a comparable hazard, and it wouldn't affect ordering
>>> anyway. So it's probably no worse than any other object-rename situation.
>>> regards, tom lane
> Is there a way or a procedure we can go through to make the these ALTER
> TYPE enhancements a higher priority? How do you choose which
> features/enhancements to implement (next)?
I was bored and thought "how hard could it be?", and a few hours'
hacking later, I have something that seems to work. It doesn't do IF
NOT EXISTS yet, and the error messaging could do with some improvement,
and there are no docs. The patch is attached, as well as at
|Next Message||Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=||2016-03-24 18:18:11||Re: Alter or rename enum value|
|Previous Message||Alvaro Herrera||2016-03-24 17:51:29||Re: Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used|