Re: [BUGS] BUG #14825: enum type: unsafe use?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: balazs(at)obiserver(dot)hu
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [BUGS] BUG #14825: enum type: unsafe use?
Date: 2017-09-22 21:46:08
Message-ID: 15165.1506116768@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

balazs(at)obiserver(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Joel Hoffman 2017-09-22 23:05:00 Multiple evaluation of single reference to function with out parameters
Previous Message balazs 2017-09-22 18:59:04 BUG #14825: enum type: unsafe use?

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2017-09-22 22:12:01 Re: Small improvement to compactify_tuples
Previous Message Robert Haas 2017-09-22 21:09:09 Re: [Proposal] Make the optimiser aware of partitions ordering