| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Matthias Kurz <m(dot)kurz(at)irregular(dot)at>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Alter or rename enum value |
| Date: | 2016-03-26 14:25:41 |
| Message-ID: | 3202.1459002341@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2016-03-26 14:40:28 | Re: Alter or rename enum value |
| Previous Message | Tom Lane | 2016-03-26 14:16:23 | Re: If a schema is created as part of an extension, should all user created tables created in that schema be considered part of the extension? |