Re: DROP OWNED BY fails to clean out pg_init_privs grants
От | Robert Haas |
---|---|
Тема | Re: DROP OWNED BY fails to clean out pg_init_privs grants |
Дата | |
Msg-id | CA+TgmobS0gjkiOwDB_6zTWenKPTqiBC=K4rxV1LPYFD_k6y3qQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: DROP OWNED BY fails to clean out pg_init_privs grants (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: DROP OWNED BY fails to clean out pg_init_privs grants
|
Список | pgsql-hackers |
On Fri, May 24, 2024 at 11:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thinking about this some more: the point of pg_init_privs is to record > an object's privileges as they stood at the end of CREATE EXTENSION > (or extension update), with the goal that pg_dump should be able to > compute the delta between that and the object's current privileges > and emit GRANT/REVOKE commands to restore those current privileges > after a fresh extension install. (We slide gently past the question > of whether the fresh extension install is certain to create privileges > matching the previous pg_init_privs entry.) +1 to all of this. > So this goal seems to > mean that neither ALTER OWNER nor REASSIGN OWNED should touch > pg_init_privs at all, as that would break its function of recording > a historical state. Only DROP OWNED should get rid of pg_init_privs > grants, and that only because there's no choice -- if the role is > about to go away, we can't hang on to a reference to its OID. But I would have thought that the right thing to do to pg_init_privs here would be essentially s/$OLDOWNER/$NEWOWNER/g. I know I'm late to the party here, but why is that idea wrong? -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: