From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pedro Gimeno <pgsql-001(at)personal(dot)formauri(dot)es> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Revisiting BUG #3684: After dump/restore, schema PUBLIC always exists |
Date: | 2007-11-09 17:03:34 |
Message-ID: | 11809.1194627814@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Pedro Gimeno <pgsql-001(at)personal(dot)formauri(dot)es> writes:
> ... it's usually assumed that the purpose of a backup
> is to be able to get things to the exact same state as they were when
> it was created.
The hole in your argument is that this is not so. The purpose of a
backup is to get the *user's* objects into the same state they were in.
If we applied that reasoning to *system* objects then presumably loading
a dump from an 8.2 database into 8.3 would magically destroy all the new
features in 8.3 (eg all the text search objects).
It might be that the public schema should be considered a user object
not a system object, but you need to make a case specifically about
that, not argue that the behavior is broken in general.
What I would personally suggest is that rather than insisting on public
not being there, you just do
revoke create on schema public from public;
which is a property that pg_dump *will* preserve.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-11-09 17:20:27 | Re: BUG #3738: psql crashes on exit. |
Previous Message | Douglas Toltzman | 2007-11-09 16:53:57 | Re: BUG #3736: server cannot listen |