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
