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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Дата
Msg-id 24698.1294286901@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Bruce Momjian <bruce@momjian.us>)
Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Andrew Dunstan <andrew@dunslane.net>)
Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Robert Haas <robertmhaas@gmail.com>)
Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Florian Pflug <fgp@phlo.org>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I think pg_dumpall would have failed with this setup too, so I don't see
>> this as a pg_upgrade bug, nor something that I am willing to risk adding
>> to pg_upgrade.

> If adding RESET SESSION AUTHORIZATION fixes the bug, I think we should
> consider doing that.

I think an appropriate response would be to prevent ALTER DATABASE SET
ROLE.  I really cannot believe that there are any situations where
that's a good idea.

Or we could take the approach somebody was just espousing about 

> Our job is to prevent the user from *accidentally*
> shooting themselves in the foot.

If they want to deliberately shoot themselves in the foot by hosing the
login system like that, it's not our job to prevent it.  But it's not
our job to try to work around it, either.
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE