Re: BUG #14825: enum type: unsafe use?
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: "David E. Wheeler" <david@justatheory.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Christophe Pettus <christophe.pettus@pgexperts.com>,
pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
Date: 2017-09-25T18:17:09Z
Lists: pgsql-bugs, pgsql-hackers
On 09/25/2017 01:34 PM, David E. Wheeler wrote: > On Sep 25, 2017, at 10:55, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote: > >> Let's ask a couple of users who I think are or have been actually >> hurting on this point. Christophe and David, any opinions? > If I understand the issue correctly, I think I’d be fine with requiring ALTER TYPE ADD LABEL to be disallowed in a transaction that also CREATEs the type if it’s not currently possible to reliably tell when an enum was created in a transaction. Once you can do that, then by all means allow it! > OK, that seems to be the consensus. So let's apply the blacklist patch and then separately remove the 'created in the same transaction' test. We'll need to adjust the regression tests and docs accordingly. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.
- 28e072707685 11.0 landed
- 93a1af0b3f63 10.0 landed
-
Remove heuristic same-transaction test from check_safe_enum_use().
- 01c5de88ff24 10.0 landed
- 984c92074d84 11.0 landed
-
Use a blacklist to distinguish original from add-on enum values.
- 175774d2932d 10.0 landed
- 1635e80d30b1 11.0 landed
-
Add support for coordinating record typmods among parallel workers.
- cc5f81366c36 11.0 cited