From: Tom Lane <tgl@sss.pgh.pa.us>
To: balazs@obiserver.hu
cc: pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org,
        Andrew Dunstan <andrew@dunslane.net>
Subject: Re: [BUGS] BUG #14825: enum type: unsafe use?
In-reply-to: <20170922185904.1448.16585@wrigleys.postgresql.org>
References: <20170922185904.1448.16585@wrigleys.postgresql.org>
Comments: In-reply-to balazs@obiserver.hu
	message dated "Fri, 22 Sep 2017 18:59:04 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15164.1506116768.1@sss.pgh.pa.us>
Date: Fri, 22 Sep 2017 17:46:08 -0400
Message-ID: <15165.1506116768@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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

			regards, tom lane


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