On 4/12/15 11:55 PM, Sameer Kumar wrote: > > On Mon, 13 Apr 2015 11:35 Jim Nasby <Jim.Nasby@bluetreble.com > <mailto:Jim.Nasby@bluetreble.com>> wrote: > > On 4/11/15 4:11 PM, Sameer Kumar wrote: > > Pg_settings currently has an upper bound column - though it is a > > view and that value cannot be changed that I know of. > > > > > > I guess that upper bound column is more of the limit that is > imposed by > > system which you can have for a parameter i.e. the system imposed > limit > > or valid range if values for a parameter. I don't think one can > update that. > > Correct. > > > But if it could I suspect that whatever catalog you would > change to > > affect it would only cause a global change. There is no alter > > database, role, or postgresql way to change that value. > > > > Oh ok... anyway of achieving that? There no EVENT trigger for > "alter user"? > > There is not, but as David mentioned there's way more ways to modify > settings than just ALTER ROLE. Attempting to lock that down won't help > you at all. > > Unfortunately, there's no hook support for doing something special when > GUCs change, though it might be possible to do something here via > planner hooks. That would be pretty complicated and would need to be > done in C. > > It doesn't look like SELinux would help either. > > So basically, there is currently no way to restrict someone changing > GUCs, other than GUCs that are marked as superuser-only. > > Is there anything ecpected in any of the near future release?
No. I suspect the community would support at least a hook for GUC changes, if not a full-on permissions system. A hook would make it fairly easy to add event trigger support.
I hope someone out there is listening :)
I hope I have made my concern clear, I currently don't have a way to control users from changing the parameter values for their own settings, which allows each user to set in-appropriate values e.g. for work_mem.