From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Subject: Re: [BUGS] BUG #14825: enum type: unsafe use?
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: balazs@obiserver.hu, pgsql-bugs@postgresql.org,
 pgsql-hackers@postgresql.org
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>
Message-ID: <f29e2d7e-7d71-b3b7-2fed-d52bddd8ca61@2ndQuadrant.com>
Date: Sat, 23 Sep 2017 08:41:25 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <28968.1506136792@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-MW
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 09/22/2017 11:19 PM, Tom Lane wrote:
> 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.


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. Maybe we should also keep a cache of whitelisted enums
created in the current transaction.

I'm not to worried about people creating a zillion enums (or enum labels
being added for the solution I had in mind). Even a hash of a million
Oids will only consume a few megabytes, won't it?

>
> 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 :-(

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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