Re: pg_dump DROP commands and implicit search paths

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump DROP commands and implicit search paths
Date: 2002-05-14 01:43:18
Message-ID: 005b01c1fae8$b9a4b360$8001a8c0@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-14 02:03:00 Re: Discontent with development process (was:Re: pgaccess - the discussion is over)
Previous Message Tatsuo Ishii 2002-05-14 01:29:54 Re: [HACKERS] Bug #659: lower()/upper() bug on