Re: Alter or rename enum value

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Christophe Pettus <xof@thebuild.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "David G. Johnston" <david.g.johnston@gmail.com>, Matthias Kurz <m.kurz@irregular.at>, Jim Nasby <Jim.Nasby@bluetreble.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-03-27T12:57:35Z
Lists: pgsql-hackers

On 03/27/2016 12:43 AM, Christophe Pettus wrote:
> On Mar 26, 2016, at 7:40 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> It would be nice if we could find a less broad brush approach to dealing with the issue.
> I don't know how doable this is, but could we use the existing mechanism of marking an index invalid if it contains an enum type to which a value was added, and the transaction was rolled back?  For the 90% use case, that would be acceptable, I would expect.
>


The more I think about this the more I bump up against the fact that 
almost anything we do might want to do to ameliorate the situation is 
going to be rolled back. The only approach I can think of that doesn't 
suffer from this is to abort if an insert/update will affect an index on 
a modified enum. i.e. we prevent the possible corruption from happening 
in the first place, as we do now, but in a much more fine grained way.

cheers

andrew


Commits

  1. Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).

  2. Partially restore comments discussing enum renumbering hazards.

  3. Allow adding values to an enum type created in the current transaction.