On 09/22/2017 05:46 PM, Tom Lane wrote: > bal...@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-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers