From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
Cc: | Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <joe(at)crunchydata(dot)com> |
Subject: | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Date: | 2022-03-30 15:45:53 |
Message-ID: | 223665.1648655153@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
> Your proposal to just punt on supporting revocation of set on userset from public seems fine. We could revisit that in the next development cycle if anyone really wants to defend it. In particular, I don't see that committing this feature without that part would create any additional backward compatibility problems when implementing that later.
Yeah. Also, as you noted, we could mark some individual built-in
variables as SUSET and add a default GRANT. I don't want to do that with
a blunderbuss, but perhaps there's an argument to do it for specific
cases (search_path comes to mind, though the performance cost could be
significant, since I think setting that in function SET clauses is
common).
For now, though, saying that you can't restrict SET for USERSET variables
seems fine --- there's certainly no loss of capability compared to where
we stand today. I'd prefer to get the feature committed in that form
and then look at whether we want to tighten things around the margins.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-03-30 15:50:17 | Re: Adding CI to our tree |
Previous Message | David G. Johnston | 2022-03-30 15:44:53 | Re: Granting SET and ALTER SYSTE privileges for GUCs |