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  (Bruno Wolff III <bruno@wolff.to>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: a question about the installation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] split_part bug