On Mon, Apr 13, 2015 at 1:03 PM Jim Nasby <jim.na...@bluetreble.com> wrote:
> On 4/12/15 11:55 PM, Sameer Kumar wrote: > > > > On Mon, 13 Apr 2015 11:35 Jim Nasby <jim.na...@bluetreble.com > > <mailto:jim.na...@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. Regards Sameer
