Re: Alter or rename enum value
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Christophe Pettus <xof@thebuild.com>,
"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-27T14:20:27Z
Lists: pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes: > 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. Perhaps, instead of forbidding ALTER ENUM ADD in a transaction, we could allow that, but not allow the new value to be *used* until it's committed? This could be checked cheaply during enum value lookup (ie, is xmin of the pg_enum row committed). What you really need is to prevent the new value from being inserted into any indexes, but checking that directly seems far more difficult, ugly, and expensive than the above. I do not know whether this would be a meaningful improvement for common use-cases, though. (It'd help if people were more specific about the use-cases they need to work.) regards, tom lane
Commits
-
Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).
- 212fab9926b2 12.0 landed
-
Partially restore comments discussing enum renumbering hazards.
- c9e2e2db5c20 9.4.0 cited
-
Allow adding values to an enum type created in the current transaction.
- 7b90469b7176 9.3.0 cited