On 2012-12-01 10:55:09 -0500, Bruce Momjian wrote: > On Sat, Dec 1, 2012 at 10:41:06AM -0500, Bruce Momjian wrote: > > OK, I found the problem, and it isn't good. Our manual clearly says: > > > > ALTER TYPE ... ADD VALUE (the form that adds a new value > > to an enum type) cannot be executed inside a transaction block. > > > > so maybe that's how we have to go, or modify pg_dump to emit the > > binary-upgrade function call as a separate pg_dump entry, rather than > > lumping it in with ALTER TYPE ... ADD VALUE. > > Scratch that idea. By definition, no matter how we modify pg_dump or > pg_restore, ALTER TYPE ... ADD VALUE is never going to be able to be run > in a multi-statement transaction, so we have to certainly remove > --single-transction, and then we can decide if we want to continue using > pg_restore with an improved pg_dump, or just fall back to pg_dump and > psql. > > I am thinking at this point I should just switch to pg_dump text format > and psql to get the build farm green again, but not lose the other > changes that give us per-database dumps. > > This does make me wonder why pg_restore supports --single-transaction if > it has known failure cases (that are not documented in the pg_restore > manual page, only in the ALTER TYPE manual page). Are users really > going to know if their database has objects that are not supported by > --single-transaction?
Could we possibly allow adding enum values to a type which was just created in this transaction? That shouldn't be too hard. At least easier than providing the capability to pre-assign the next N oids... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
