Re: 12 to 13 migration, the privs error with pg_pltemplate
От | Scott Ribe |
---|---|
Тема | Re: 12 to 13 migration, the privs error with pg_pltemplate |
Дата | |
Msg-id | 68634B7E-3AD0-42A3-9A2D-EC3988E755E4@elevated-dev.com обсуждение исходный текст |
Ответ на | Re: 12 to 13 migration, the privs error with pg_pltemplate (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 12 to 13 migration, the privs error with pg_pltemplate
|
Список | pgsql-admin |
> On Dec 9, 2020, at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Scott Ribe <scott_ribe@elevated-dev.com> writes: >> Any other suggestions? What could possibly be triggering this GRANT? > > 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. OK, now *THAT* turned up a lot of suspicious entries. It will be a bit before I can try straightening that out. But there'sa lot of tables in pg_catalog that have privs listed for the user in question.
В списке pgsql-admin по дате отправления: