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
Subject: Re: BUG #14825: enum type: unsafe use?
In-reply-to: <f29e2d7e-7d71-b3b7-2fed-d52bddd8ca61@2ndQuadrant.com>
References: <20170922185904.1448.16585@wrigleys.postgresql.org>
 <15165.1506116768@sss.pgh.pa.us>
 <3cece400-af56-7145-2e65-f044de1b0b68@2ndQuadrant.com>
 <28968.1506136792@sss.pgh.pa.us>
 <f29e2d7e-7d71-b3b7-2fed-d52bddd8ca61@2ndQuadrant.com>
Comments: In-reply-to Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
	message dated "Sat, 23 Sep 2017 08:41:25 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24379.1506179805.1@sss.pgh.pa.us>
Date: Sat, 23 Sep 2017 11:16:45 -0400
Message-ID: <24380.1506179805@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 09/22/2017 11:19 PM, Tom Lane wrote:
>> 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.

> I see what you're saying, but my idea was slightly different. We would
> only add to the hashtable I had in mind at the bottom AddEnumLabel().
> Any other value, whether added in the current transaction or not, should
> be safe, AIUI.

Oh, I see: a list of enum values we need to blacklist, not whitelist.
Yes, that's a significantly better idea than mine, because in common
use-cases that would be empty or have a very small number of entries.
In particular that fixes the "pg_restore -1" scenario, because no
matter how many enums you're restoring, pg_dump doesn't use ALTER
TYPE ADD VALUE.  (Well, it does in --binary-upgrade mode, but those
scripts are run in transaction-per-statement mode so it's fine.)

> Maybe we should also keep a cache of whitelisted enums
> created in the current transaction.

What for?  Wouldn't be any faster to search, in fact likely slower
because it could get large in common use-cases.

>> 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.

> Sadly I agree. We've made decisions like this in the past, and I have
> generally been supportive of them. I think this is the first time I have
> been on the receiving end of one so late in the process :-(

Unless you want to try writing a patch for this in the next day or two,
I think we have to do that.  But now that I see the plan clearly, maybe
we could get away with a post-RC1 fix.

			regards, tom lane


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs