Re: reset all update
От | Tom Lane |
---|---|
Тема | Re: reset all update |
Дата | |
Msg-id | 26303.992443161@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: reset all update (Marko Kreen <marko@l-t.ee>) |
Ответы |
Re: reset all update
Re: reset all update |
Список | 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 по дате отправления: