Re: pg_dump DROP commands and implicit search paths - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: pg_dump DROP commands and implicit search paths
Date
Msg-id 005b01c1fae8$b9a4b360$8001a8c0@jester
Whole thread Raw
In response to pg_dump DROP commands and implicit search paths  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump DROP commands and implicit search paths  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Doesn't seem very workable for the public schema.  I suspect pg_dump
> has to special-case public anyway, to some extent, but this doesn't
> really get us around the DROP problem for individual objects AFAICS.

Most people in the know will probably never use public due to
portability issues between other databases.  A dump without create
public won't work anywhere but Postgresql -- which is fine.

So fully qualifying public entries isn't so bad -- especially if it's
only public entries.  After a few more releases (7.[56])public may be
able to be treated as a standard user created schema where its
creation is prepended from dumps from before 7.3.

How did you intend on dealing with the case where a user removes
public or otherwise changes the permissions / ownership on it?  Is the
assumption going to be made that it always exists and is world
writable?  Obviously restoring dumps from 7.2 or earlier will require
public in that state, but will 7.3 and later require it as well where
there are objects stored in it?



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [BUGS] Bug #659: lower()/upper() bug on
Next
From: Tom Lane
Date:
Subject: Re: Discontent with development process (was:Re: pgaccess - the discussion is over)