Re: [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: "Karl O(dot) Pinc" <kop(at)meme(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug
Date: 2004-11-18 03:17:49
Message-ID: 20041118031749.GA14689@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Nov 17, 2004 at 11:53:10 -0800,
Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Karl,
>
> > I don't care that much about the behavior, it's easy enough
> > to delete 'public'.  I do think that a note should be
> > made in the administrator manual regards system upgrades
> > where pg_dump(all) scripts are given if this is going to be
> > the behavior.
>
> This isn't isolated to the "public" schema. In fact, anything which is in
> the template database (usually template1) will be in the database you reload,
> even if it wasn't in the original database. The result is that when you try
> to remove built-in objects that ship with PostgreSQL, they are "replaced" on
> a new migration server. pg_dump isn't capable of working around this, nor
> should it be.
>
> Search the archives of -Hackers mailing list for this issue; a few
> workarounds were suggested.

I am pretty sure that the last time this was discussed, it was pointed out
that pg_dump(all) and pg_restore are relative to template0, not template1.
(Though by default template1 will be the same as template0.)

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PostgreSQL Bugs List 2004-11-18 10:14:21 BUG #1325: like error
Previous Message Michael Fuhr 2004-11-18 02:08:27 Re: [COMMITTERS] pgsql: Remove ill-considered suppression of gcc warnings in plperl, and