Re: [PATCH] Alter or rename enum value
Emre Hasegeli <emre@hasegeli.com>
From: Emre Hasegeli <emre@hasegeli.com>
To: Matthias Kurz <m.kurz@irregular.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Jim Nasby <Jim.Nasby@bluetreble.com>, "David G. Johnston" <david.g.johnston@gmail.com>
Date: 2016-09-08T09:55:12Z
Lists: pgsql-hackers
> Given that you are now familiar with the internals of how enums are > implemented would it be possible to continue the work and add the "ALTER > TYPE <name> DROP VALUE <somevalue>" command? I was thinking to try developing it, but I would be more than happy to help by testing and reviewing, if someone else would do. I don't think I have enough experience to think of all details of this feature. The main problem that has been discussed before was the indexes. One way is to tackle with it is to reindex all the tables after the operation. Currently we are doing it when the datatype of indexed columns change. So it should be possible, but very expensive. Another way, Thomas Munro suggested when we were talking about it, would be to add another column to mark the deleted rows to the catalog table. We can check for this column before allowing the value to be used. Indexes can continue using the deleted values. We can also re-use those entries when someone wants to add new value to the matching place. It should be safe as long as we don't update the sort order.
Commits
-
Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).
- 212fab9926b2 12.0 landed
-
Partially restore comments discussing enum renumbering hazards.
- c9e2e2db5c20 9.4.0 cited
-
Allow adding values to an enum type created in the current transaction.
- 7b90469b7176 9.3.0 cited