On Fri, Jul 22, 2022 at 04:16:14PM -0400, Tom Lane wrote:
> Clearly, you need enough privilege to SET the parameter, and you need
> some sort of management privilege on the target role or DB. There
> might be room to discuss what that per-role/DB privilege needs to be.
> But I'm very skeptical that we need to manage this at the level
> of the cross product of GUCs and roles/DBs, which is what you seem
> to be proposing. That seems awfully unwieldy, and is there really
> any use-case for it?
Actually, I think my vote is to do nothing, except for perhaps updating the
documentation to indicate that SET privileges on a parameter are sufficient
for ALTER ROLE/DATABASE SET (given you have the other required privileges
for altering the role/database). I can't think of a use-case for allowing
a role to SET a GUC but not change the session default for another role.
And I agree that requiring extra permissions for this feels excessive.
Maybe someone else has a use-case in mind, though. I figured it would be
good to hash this out prior to 15.0, at which point changing the behavior
would become substantially more difficult.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
