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