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
Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE |
Список | 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 по дате отправления: