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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
