From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Subject: Re: BUG #14825: enum type: unsafe use?
To: Tom Lane <tgl@sss.pgh.pa.us>, balazs@obiserver.hu
Cc: pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
References: <20170922185904.1448.16585@wrigleys.postgresql.org>
 <15165.1506116768@sss.pgh.pa.us>
Message-ID: <3cece400-af56-7145-2e65-f044de1b0b68@2ndQuadrant.com>
Date: Fri, 22 Sep 2017 21:27:29 -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: <15165.1506116768@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-MW
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org


On 09/22/2017 05:46 PM, Tom Lane wrote:
> balazs@obiserver.hu writes:
>> PostgreSQL version: 10beta4
>> testdb=# begin;
>> BEGIN
>> testdb=# create type enumtype as enum ('v1', 'v2');
>> CREATE TYPE
>> testdb=# alter type enumtype owner to testrole;
>> ALTER TYPE
>> testdb=# create table testtable (enumcolumn enumtype not null default 'v1');
>> ERROR:  unsafe use of new value "v1" of enum type enumtype
>> HINT:  New enum values must be committed before they can be used.
> Hmm, that's pretty annoying.  It's happening be

> cause check_safe_enum_use
> insists that the enum's pg_type entry not be updated-in-transaction.
> We thought that the new rules instituted by 15bc038f9 would be generally
> more convenient to use than the old ones --- but this example shows
> that, for example, pg_dump scripts involving enums often could not
> be restored inside a single transaction.
>
> 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.


:-(


The only real problem comes from adding a value to an enum that has been
created in an earlier transaction and then using that enum value. What
we're doing here is essentially a heuristic test for that condition, and
we're getting some false positives. 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.

cheers

andrew

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


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