Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
От | Tom Lane |
---|---|
Тема | Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES |
Дата | |
Msg-id | 1737876.1634613552@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES |
Список | pgsql-bugs |
Masahiko Sawada <sawada.mshk@gmail.com> writes: > I've looked at the patch proposed you proposed. If we can depend on > acldefault() being STRICT (which is legitimate to me), I think we > don't need to build an expression depending on the caller (i.g., > is_default_acl). If acldefault() were to become not STRICT, we could > detect it by regression tests. What do you think? FWIW, I'm working on a refactoring of this logic that will bring the acldefault() call into the getDefaultACLs code, which would mean that we won't need that assumption anymore anyway. The code as I have it produces SQL like acldefault(CASE WHEN defaclobjtype = 'S' THEN 's'::"char" ELSE defaclobjtype END, defaclrole) AS acldefault and we could wrap the test-for-zero around that: CASE WHEN defaclnamespace = 0 THEN acldefault(CASE WHEN defaclobjtype = 'S' THEN 's'::"char" ELSE defaclobjtype END, defaclrole) ELSE NULL END AS acldefault (although I think it might be better to write ELSE '{}' not ELSE NULL). So I think we don't need to worry about whether acldefault() will stay strict. This patch will only need to work in the back branches. regards, tom lane
В списке pgsql-bugs по дате отправления: