Re: BUG #14009: pg_restore not restoring privilegs when one login/group role is missing
От | Tom Lane |
---|---|
Тема | Re: BUG #14009: pg_restore not restoring privilegs when one login/group role is missing |
Дата | |
Msg-id | 4509.1457627094@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #14009: pg_restore not restoring privilegs when one login/group role is missing (Alexander Spiteri <alexander@spiteri.org>) |
Ответы |
Re: BUG #14009: pg_restore not restoring privilegs when one
login/group role is missing
|
Список | pgsql-bugs |
Alexander Spiteri <alexander@spiteri.org> writes: > Please find a test case attached. I tried to put as much detail as i could. Okay, I see what's going on. I really doubt that there is a regression here from 8.4 though. I will bet that the difference is you used plain text output from pg_dump back in 8.4, and now in 9.5 you are trying to use pg_restore direct-to-database mode. The proximate cause of the problem is that pg_dump bundles up GRANT/REVOKE statements for any object into a single "ACL" entry in the archive file. If you dump to SQL text this doesn't matter because it just looks like a stream of separate statements. But if pg_restore is trying to restore direct to database then it issues the whole text of each archive file entry as a single PQexec() operation, which means that an error in one statement in that string causes the rest of 'em to be skipped. As a short-term workaround you could try restoring in this way: pg_restore foo.dump | psql To really fix it, I think we'd need either to expand "ACL" archive entries into a separate entry for each target user, or to change pg_restore to parse the entry contents into separate statements. The latter seems messy and bug-prone. The former solution wouldn't fix the problem for dumps from existing pg_dump versions; but on the other hand, it might provide additional flexibility for selective restores, so I'm not sure that it's a bad idea going forward. regards, tom lane
В списке pgsql-bugs по дате отправления: