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
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 |