From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Kreen <marko(at)l-t(dot)ee> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: reset all update |
Date: | 2001-06-13 14:39:21 |
Message-ID: | 26303.992443161@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Marko Kreen <marko(at)l-t(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2001-06-13 14:54:48 | Re: Patch to warn about oid/xid wraparound |
Previous Message | Marko Kreen | 2001-06-13 14:36:06 | Re: reset all update |