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>
Subject: Re: Alter or rename enum value
In-reply-to: <56F6827F.9040104@dunslane.net>
References: 
 <CAO=2mx6uvgPaPDf-rHqG8=1MZnGyVDMQeh8zS4euRyyg4D35OQ@mail.gmail.com>
 <56E049CC.8010201@dunslane.net> <25605.1457539654@sss.pgh.pa.us>
 <56E05635.70908@dunslane.net> <28167.1457543612@sss.pgh.pa.us>
 <CAO=2mx4rQHRvifT2yUQ1rz90A=9CVz4_Z0Sx1wTgwgQRzAimpQ@mail.gmail.com>
 <CAO=2mx6rK_h4BC7y+3Nu-8fuZJXdFjd9FE_MZnzkH+vnMp0C-Q@mail.gmail.com>
 <d8ja8ln7nl0.fsf@dalvik.ping.uio.no> <d8j60wb7na4.fsf@dalvik.ping.uio.no>
 <CAO=2mx6CgQXFJYXOpr4OJO+r8WX6PzEU5aT+K0vV94G7DxVJ0A@mail.gmail.com>
 <56F49CF8.8050007@BlueTreble.com> <27476.1458876456@sss.pgh.pa.us>
 <CAO=2mx6EOh6uQQ57Kv2z0x=kuyVbkEbwiY8R2h6VCPL=Fxe5wg@mail.gmail.com>
 <56F58876.6020508@dunslane.net>
 <CAKFQuwZeVdo=qQy-WV_hfqy0Wsit9tuhtZOLsq1Jx82eKc8bfQ@mail.gmail.com>
 <56F6827F.9040104@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Sat, 26 Mar 2016 08:37:19 -0400"
Date: Sat, 26 Mar 2016 10:25:41 -0400
Message-ID: <3202.1459002341@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers