Re: Allow deleting enumerated values from an existing enumerated data type
Vik Fearing <vik@postgresfriends.org>
From: Vik Fearing <vik@postgresfriends.org>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>
Cc: Данил Столповских <danil.stolpovskikh@gmail.com>, pgsql-hackers@postgresql.org, o.tselebrovskiy@postgrespro.ru, d.frolov@postgrespro.ru
Date: 2023-09-29T00:36:53Z
Lists: pgsql-hackers
Attachments
- dropenum.diff (text/x-patch) patch
On 9/28/23 20:46, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> I wonder if we could have a boolean flag in pg_enum, indicating that >> setting an enum to that value was forbidden. > > Yeah, but that still offers no coherent solution to the problem of > what happens if there's a table that already contains such a value. > It doesn't seem terribly useful to forbid new entries if you can't > get rid of old ones. > > Admittedly, a DISABLE flag would at least offer a chance at a > race-condition-free scan to verify that no such values remain > in tables. But as somebody already mentioned upthread, that > wouldn't guarantee that the value doesn't appear in non-leaf > index pages. So basically you could never get rid of the pg_enum > row, short of a full dump and restore. > > We went through all these points years ago when the enum feature > was first developed, as I recall. Nobody thought that the ability > to remove an enum value was worth the amount of complexity it'd > entail. This issue comes up regularly (although far from often). Do we want to put some comments right where would-be implementors would be sure to see it? Attached is an example of what I mean. Documentation is intentionally omitted. -- Vik Fearing
Commits
-
Add some notes about why "ALTER TYPE enum DROP VALUE" is hard.
- af3ee8a086ca 17.0 landed