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

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug
Date: 2004-11-17 19:53:10
Message-ID: 200411171153.10997.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-11-17 21:23:37 pgsql: Remove ill-considered suppression of gcc warnings in plperl, and
Previous Message Josh Berkus 2004-11-17 19:34:55 a question about the installation