Horton

Re: [BUGS] 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: balazs@obiserver.hu
Cc: pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Date: 2017-09-22T21:46:08Z
Lists: pgsql-bugs, pgsql-hackers 
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

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.