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