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
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? |
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 |