From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Date: | 2021-11-17 17:05:53 |
Message-ID: | CA+TgmoaBSBv+fPh6uEsmdL+pvwCsjKcj4iT3aigOQKa2NEK73g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 17, 2021 at 9:31 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Well, I was trying (perhaps not very well) to imagine how to deal with
> someone modifying the permissions of one of the predefined roles. Say
> pg_foo has initial permission to set bar and baz, and the DBA removes
> permission to set baz. How is pg_dump going to emit the right commands
> to allow a safe pg_upgrade? Maybe we should say that the permissions for
> the predefined roles are immutable, so only permissions sets for user
> defined roles are mutable.
That's a great question, but it isn't a new problem. If I create a
brand new database and do thIs:
rhaas=# revoke execute on function pg_ls_waldir() from pg_monitor;
REVOKE
And then I do this:
[rhaas pgsql]$ pg_dump
Then the output includes this:
REVOKE ALL ON FUNCTION pg_catalog.pg_ls_waldir(OUT name text, OUT size
bigint, OUT modification timestamp with time zone) FROM pg_monitor;
I recommend looking at how that works and making this work the same way.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-11-17 17:06:50 | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Previous Message | Bharath Rupireddy | 2021-11-17 16:54:18 | Re: pg_waldump stucks with options --follow or -f and --stats or -z |