Andy Shellam writes:
> I've just re-created this using the following steps on a blank database:
> 1. Create a new database using a role with a default search path of
> "$user", public.
> 2. Create a schema in that database (myschema)
> 3. Create a sequence in the test schema (mysequence)
> 4. Cr
No, it isn't. If the search_path was "product" when the table
definition was loaded,
No it wasn't. When the table was initially created (from scratch not
from the dump) the search path was the default of "$user", public.
I've just re-created this using the following steps on a blank data
Andy Shellam writes:
> Yes, that's true - it's in the search path because (so I believe)
> pg_dump is adding a "SET search_path..." line before it carries out the
> commands in the schema, which works when the dump is restored, but when
> running as a normal user, the search path is the default
Hi Tom
The reason it's printed as just 'tax_id' is that that relation should be
first in the search_path at this point.
Yes, that's true - it's in the search path because (so I believe)
pg_dump is adding a "SET search_path..." line before it carries out the
commands in the schema, which wor
Andy Shellam writes:
> When I pg_dump the schema, the resulting SQL is:
> ...
> CREATE SCHEMA product;
> ...
> SET search_path = product, pg_catalog;
> ...
> CREATE SEQUENCE tax_id
> INCREMENT BY 1
> NO MAXVALUE
> NO MINVALUE
> CACHE 1;
> ...
> CREATE TABLE tax (
> id smallint
I've come across an issue with pg_dump from 8.3.7 (running on Windows.)
I'm using pg_dump to dump the schema only of the database for a system
I'm currently displaying.
The other day I had to re-create the database using the latest dump, and
for a lot of the tables I now get the error "relati
