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
-
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