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: "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-26T14:25:41Z
Lists: pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> We don't have the luxury of being able to redesign this as a green 
> fields development.

I'm not actually convinced that we need to do anything.  SQL already has a
perfectly good mechanism for enforcing that a column contains only values
of a mutable set defined in another table --- it's called a foreign key.
The point of inventing enums was to provide a lower-overhead solution
for cases where the allowed value set is *not* mutable.  So okay, if we
can allow certain cases of changing the value set without increasing
the overhead, great.  But when we can't do it without adding a whole
lot of complexity and overhead (and, no doubt, bugs), we need to just
say no.

Maybe the docs about enums need to be a little more explicit about
pointing out this tradeoff.

			regards, tom lane


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.