On 03/26/2016 10:25 AM, Tom Lane wrote:
Andrew Dunstan <and...@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.
OK, but we (in fact, you and I, for the most part) have provided a way
to add new values. The trouble people have is the transaction
restriction on that facility, because all the other changes they make
with migration tools can be nicely wrapped in a transaction. And the
thing is, in my recent experience on a project using quite a few enums,
none of the transactions I'd like to include these mutations of enums in
does anything that would be at all dangerous. It would be nice if we
could find a less broad brush approach to dealing with the issue.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
