Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c
От | Tom Lane |
---|---|
Тема | Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c |
Дата | |
Msg-id | 7737.1311861960@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: patch: move dumpUserConfig call in dumpRoles function of pg_dumpall.c (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: patch: move dumpUserConfig call in dumpRoles function
of pg_dumpall.c
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Jul 27, 2011 at 7:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think pg_dumpall is the very least of your problems if you do >> something like that. �We probably ought to forbid it entirely. > Well, we had a long discussion of that on the thread Phil linked to, > and I don't think there was any consensus that forbidding it was the > right thing to do. You're right, I was half-remembering that thread and thinking that there are a lot of gotchas in doing an ALTER ROLE SET ROLE. Florian claimed in the thread that he'd never hit one before, but that doesn't convince me much. > Phil appears to be trying to implement the > proposal you made here: > http://archives.postgresql.org/pgsql-hackers/2011-01/msg00452.php > ...although I don't think that what he did quite matches what you asked for. No, the proposed patch doesn't go nearly far enough to address Florian's problem. What I was speculating about was moving all the role (and database) alters to the *end*, so they'd not take effect until after we'd completed all the restore actions. regards, tom lane
В списке pgsql-hackers по дате отправления: