Horton

Re: BUG #14825: enum type: unsafe use?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: balazs@obiserver.hu, pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
Date: 2017-09-23T03:19:52Z
Lists: pgsql-bugs, pgsql-hackers 
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 09/22/2017 05:46 PM, Tom Lane wrote:
>> I'm not sure if that qualifies as a stop-ship problem, but it ain't
>> good, for sure.  We need to look at whether we should revert 15bc038f9
>> or somehow revise its rules.

> I wonder if we wouldn't be better
> doing this more directly, keeping a per-transaction hash of unsafe enum
> values (which will almost always be empty). It might even speed up the
> check.

Yeah, I was considering the same thing over dinner, though I'd phrase
it oppositely: keep a list of enum type OIDs created in the current
transaction, so that we could whitelist them.  This could maybe become
a problem if someone created a zillion enums in one xact, though.

The immediate question is do we care to design/implement such a thing
post-RC1.  I'd have to vote "no".  I think the most prudent thing to
do is revert 15bc038f9 and then have another go at it during the v11
cycle.

			regards, tom lane

Commits

  1. Revert to 9.6 treatment of ALTER TYPE enumtype ADD VALUE.

  2. Remove heuristic same-transaction test from check_safe_enum_use().

  3. Use a blacklist to distinguish original from add-on enum values.

  4. Add support for coordinating record typmods among parallel workers.