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 по дате отправления:

Предыдущее
От: "Taral"
Дата:
Сообщение: RE: [HACKERS] More PostgreSQL+CORBA
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] BIG grant problem