From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: 12 to 13 migration, the privs error with pg_pltemplate |
Date: | 2020-12-09 19:24:06 |
Message-ID: | 20201209192406.GD16415@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Greetings,
* Scott Ribe (scott_ribe(at)elevated-dev(dot)com) wrote:
> > On Dec 9, 2020, at 11:49 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > REVOKE'ing the privileges on the
> > catalog tables/columns that are causing an issue should resolve it
> > though.
>
> I tried REVOKE ALL, no joy. Given where Tom pointed me, perhaps I need to give ALTER DEFAULT PRIVILEGES a try.
Are you sure you have privileges to perform the REVOKE and that it
actually did something..? Check the results in psql using:
=> \dp pg_catalog.pg_pltemplate
(or whatever catalog table it is the GRANT's are being created for
in the pg_dump)
What you'd want is something like:
Access privileges
Schema | Name | Type | Access privileges | Column privileges | Policies
------------+---------------+-------+---------------------------+-------------------+----------
pg_catalog | pg_pltemplate | table | postgres=arwdDxt/postgres+| |
| | | =r/postgres | |
(1 row)
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2020-12-09 19:42:19 | Re: 12 to 13 migration, the privs error with pg_pltemplate |
Previous Message | Scott Ribe | 2020-12-09 19:20:32 | Re: 12 to 13 migration, the privs error with pg_pltemplate |