Re: [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug
| От | Josh Berkus |
|---|---|
| Тема | Re: [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug |
| Дата | |
| Msg-id | 200411171153.10997.josh@agliodbs.com обсуждение |
| Ответы |
Re: [pgsql-bugs] pg_dumpall (7.3) 'public' schema bug
|
| Список | pgsql-bugs |
Karl, > 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
В списке pgsql-bugs по дате отправления: