Re: reset all update - Mailing list pgsql-patches

From Tom Lane
Subject Re: reset all update
Date
Msg-id 26303.992443161@sss.pgh.pa.us
Whole thread Raw
In response to Re: reset all update  (Marko Kreen <marko@l-t.ee>)
Responses Re: reset all update
Re: reset all update
List pgsql-patches
Marko Kreen <marko@l-t.ee> writes:
> My idea was that RESET should not check permissions, all perm
> check are in set_*.  vars that are not SET-able by user, will
> have *variable == default_val, so reset can safely go through
> all of them, and not mess anything up.  But this means the
> default_val must be 'right'.

Indeed.  My feeling is the opposite: there is no scenario in which RESET
ALL should be changing variables that are POSTMASTER, BACKEND, or SIGHUP
level; therefore it's best that it not even try.  Belt-and-suspenders
programming, if you like, since I also agree that the default should be
correct.

> I still think that GUCifying cmdline is Good, because
> of the var checks.  Also, when in future there will be 'set
> hooks' which eg. (re)allocate memory, it is good when all var
> changes go through one place.

Yes, I agree with both these points.  I think you are right that
replacing all the direct assignments with GUC calls is a good idea.

I apologize for not having noticed your patch before I committed
what I was doing; the conflict is my fault.  If you have time to redo
your changes atop mine, it would be appreciated.  Otherwise I'll take
responsibility for cleaning up the mess.

BTW, I would recommend that you not add logic to suppress the assignment
when the value is not changing.  Now that there are assign_hooks for all
variable types, it seems to me that it is the assign_hook's
responsibility to decide whether it wants to optimize that case or not.

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Patch to include PAM support...
Next
From: Tom Lane
Date:
Subject: Re: Patch to include PAM support...