dbTalk Databases Forums  

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

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss Re: [BUGS] [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Josh Berkus
 
Posts: n/a

Default Re: [BUGS] [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug - 11-17-2004 , 01:59 PM






Karl,

Quote:
I don't care that much about the behavior, it's easy enough
to delete 'public'. =C2=A0I 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=
=20
the template database (usually template1) will be in the database you reloa=
d,=20
even if it wasn't in the original database. The result is that when you t=
ry=20
to remove built-in objects that ship with PostgreSQL, they are "replaced" o=
n=20
a new migration server. pg_dump isn't capable of working around this, nor=
=20
should it be.

Search the archives of -Hackers mailing list for this issue; a few=20
workarounds were suggested.

--=20
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend


Reply With Quote
  #2  
Old   
Bruno Wolff III
 
Posts: n/a

Default Re: [BUGS] [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug - 11-17-2004 , 09:09 PM






On Wed, Nov 17, 2004 at 11:53:10 -0800,
Josh Berkus <josh (AT) agliodbs (DOT) com> wrote:
Quote:
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.)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.