Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Дата
Msg-id AANLkTinqDBZBVQDbWps=cS_xHC=iW1d8o0TM-=Y3gBmm@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Florian Pflug <fgp@phlo.org>)
Список pgsql-hackers
On Sun, Dec 12, 2010 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This is about like arguing that pg_dump and pg_upgrade should still work
> after you've done "delete from pg_proc;".  Superusers are assumed to
> know what they're doing and not break fundamental operations.

No, it isn't like that at all.  You've made that argument in the past,
and it carries no water with me at all.  There's no help for the fact
that direct modification of the system catalog contents can
fundamentally break things, but DDL commands should not.  I'm willing
to reserve judgment on whether ALTER DATABASE .. SET ROLE should be
disallowed, or whether it should be made to not break things, but
blaming the DBA for shooting himself with the loaded foot-gun we
thoughtfully provided is unreasonable.

And in fact it strikes me that we might not have much choice about how
to fix this.  I think we are not going to retroactively change the
behavior of ALTER DATABASE .. SET ROLE in a released version, but yet
we do, I think, want to make pg_upgrade work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: create tablespace fails silently, or succeeds improperly
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED