Re: pg_dump and schema names - Mailing list pgsql-hackers
I was under the impression that every command that references a relation makes use of the search path, regardless of what it is *doing*. Maybe this is different in older versions though?
I actually ran into this recently and had to remove all the xx. schema components using vi before I could run the dump to move to a different schema.
Just to be sure:
postgres=# create schema test;
CREATE SCHEMA
postgres=# set search_path to test;
SET
postgres=# create table test1(id serial);
NOTICE: CREATE TABLE will create implicit sequence "test1_id_seq" for serial column "test1.id"
CREATE TABLE
postgres=# alter table test1 owner to postgres;
ALTER TABLE
Cheers,
James Sewell
Solutions Architect
_____________________________________
On Fri, Aug 9, 2013 at 2:04 PM, Bruce Momjian <bruce@momjian.us> wrote:
pg_dump goes to great lengths not to hard-code the schema name into
commands like CREATE TABLE, instead setting the search_path before
creating the table; these commands:
CREATE SCHEMA xx;
CREATE TABLE xx.test(x int);
generates this output:
SET search_path = xx, pg_catalog;
CREATE TABLE test (
x integer
);
If you dump a schema and want to reload it into another schema, you
should only need to update that one search_path line. However, later in
the dump file, we hardcode the schema name for setting the object owner:
ALTER TABLE xx.test OWNER TO postgres;
Could we use search_path here to avoid the schema designation? I am not
sure this possible because while CREATE defaults to the first existing
schema in the search_path, I am not sure ALTER has the same behavior
because you are not _creating_ something with ALTER.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.
Attachment
pgsql-hackers by date: