Re: Granting SET and ALTER SYSTE privileges for GUCs

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Joshua Brindle <joshua.brindle@crunchydata.com>, Andrew Dunstan <andrew@dunslane.net>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Joe Conway <joe@crunchydata.com>
Date: 2022-03-30T15:45:53Z
Lists: pgsql-hackers
Mark Dilger <mark.dilger@enterprisedb.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



Commits

  1. Allow granting SET and ALTER SYSTEM privileges on GUC parameters.