On 2013-01-13 12:29:08 -0500, Tom Lane wrote: > "Erik Rijkers" <e...@xs4all.nl> writes: > > If you dump a table with -t schema.table, and in the receiving database > > that schema does not > > exist, pg_restore-9.3devel will restore into the pg_catalog schema: > > ... > > Off course the workaround is obvious, but shouldn't this be prevented from > > happening in the first > > place? 9.2 refuses to do such a restore, which seems much better. > > I said to myself "huh? surely we did not change pg_dump's behavior > here". But actually it's true, and the culprit is commit 880bfc328, > "Silently ignore any nonexistent schemas that are listed in > search_path". What pg_dump is emitting is > > SET search_path = s, pg_catalog; > CREATE TABLE t (...); > > and in HEAD the SET throws no error and instead establishes pg_catalog > as the target schema for object creation. Oops. > > So obviously, 880bfc328 was several bricks shy of a load. The arguments > for that change in behavior still seem good for schemas *after* the > first one; but the situation is entirely different for the first schema, > because that's what the command is attempting to establish as the > creation schema.
There also is the seemingly independent question of why the heck its suddently allowed to create (but not drop?) tables in pg_catalog. 9.2 does: andres=# CREATE TABLE pg_catalog.c AS SELECT 1; ERROR: permission denied to create "pg_catalog.c" DETAIL: System catalog modifications are currently disallowed. Time: 54.180 ms HEAD: postgres=# CREATE TABLE pg_catalog.test AS SELECT 1; SELECT 1 Time: 124.112 ms postgres=# DROP TABLE pg_catalog.test; ERROR: permission denied: "test" is a system catalog Time: 0.461 ms Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
