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

Предыдущее
От: Phil Eaton
Дата:
Сообщение: Re: Add minimal C example and SQL registration example for custom table access methods.
Следующее
От: Andres Freund
Дата:
Сообщение: Re: First draft of PG 17 release notes