On 03/26/2016 10:25 AM, Tom Lane wrote:
> 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.
>
>
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
