Re: 12 to 13 migration, the privs error with pg_pltemplate

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: 12 to 13 migration, the privs error with pg_pltemplate
Дата
Msg-id 20201218161915.GC16415@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: 12 to 13 migration, the privs error with pg_pltemplate  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Wed, Dec  9, 2020 at 12:19:18PM -0500, Tom Lane wrote:
> >> Ah, I'm sorry, I pointed you at the wrong catalog entirely.  It's
> >> not pg_default_acl that controls this, it's pg_init_privs.  I believe
> >> what pg_dump is doing is emitting GRANT commands that replicate
> >> the difference between pg_pltemplate's current actual privileges and
> >> what is shown for it in pg_init_privs.  So you need to make those
> >> two things match, in whichever way is easiest.
>
> > Should pg_dump or pg_upgrade be detecting and reporting these things,
> > rather than requiring this analysis by the user?
>
> It's a little premature to be considering that when we still haven't
> identified exactly what the problem is.

Pretty sure we did get to the bottom of it, the OP was just in the wrong
database.

Anastasia, as I recall, had a patch that worked to avoid dumping out
privileges and such for things which disappeared but I don't think
anyone ended up finding time to review and commit it.  I do think that,
in general, that was a good effort though and it'd be nice to get it (or
something like it) committed to avoid having this issue for users who
have GRANT'd rights to pg_catalog tables that are later changed between
versions.

Thanks,

Stephen

Вложения

В списке pgsql-admin по дате отправления:

Предыдущее
От: Kanninen Anssi EXT
Дата:
Сообщение: RE: User granted all access to schema, but can't see tables
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Grant request