Re: [HACKERS] BIG grant problem
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] BIG grant problem |
Дата | |
Msg-id | 17222.911111502@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] BIG grant problem (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] BIG grant problem
Re: [HACKERS] BIG grant problem |
Список | pgsql-hackers |
Bruce Momjian <maillist@candle.pha.pa.us> writes: > Terry Mackintosh wrote: >> Minor detail, but when I did 'pg_dump -z -f dump.file dbname' and then >> went to restore it, I found that the grant statments are like: >> GRANT ALL on "tablename" to "tablename"; >> instead of >> GRANT ALL on "tablename" to "username"; > Yikes, confirmed here. We need to know how this got into the tree > without showing up on our tests, Well, that's easy --- there are no regression tests that test pg_dump at all, nor any that test multiple table owners and permissions. FWIW, pg_dump -z works correctly for GRANT to PUBLIC --- otherwise I would've noticed some time ago. But I hadn't had occasion to check granting permission to specific users :-( ... and I don't think most of the rest of the developers work with databases that even have multiple users, let alone put access restrictions on individual tables. It's certainly true that pg_dump is pretty weak in the area of table ownerships and permissions. We have fixed several bugs in that area since 6.3.2, and I'm not particularly surprised to hear of another one. We need someone who actually has occasion to work with access-restricted databases to pound on pg_dump for a while and flush out the bugs. (Terry, can you volunteer?) I don't think the bugs will be hard to fix, it's just a matter of not having done enough testing. regards, tom lane
В списке pgsql-hackers по дате отправления: