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

Greetings,

* Scott Ribe (scott_ribe(at)elevated-dev(dot)com) wrote:
> However, I was in the database postgres when I did all of that. I needed to execute REVOKE in the target database. That fixed it. What is also interesting, is that psql's \dp command apparently always looks at the global privs:

Yes, I specifically asked if you were looking at the correct database
previously, because it matters:

* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> Are you sure you're looking at the right database? Do you see GRANT or
> REVOKE commands for that table when you run pg_dump by hand..?

[ ... ]

> Seems confusing--like one can create an entry in a db to set privs on a table in a different db, or one can create a default in a user db to set privs on a catalog db??? Is this even possible in normal PG commands, or am I looking at the debris of an ancient erroneous attempt to directly manipulate system catalogs?

The reality is that pg_class is a per-database catalog table and that's
where ACLs are stored, so you can easily end up with privileges
associated with a shared catalog table which are different in different
databases- just depends which database you're connected to when you
issue the GRANT commands.

I'm pretty sure none of this has anything to do with DEFAULT PRIVILEGES
as those only actually apply when a new table is created (and not from a
template database), and that's just never the case with any PG catalog
tables.

What might be useful to point out is that only a superuser can change
the privileges associated with PG catalog tables and that you really
should be careful who you grant superuser privileges to.

Thanks,

Stephen