Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> 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.
> This assume the assign hooks have no negative effects. Should we call
> them if the value isn't changed?
It's the hook's responsibility not to do anything that's incorrect.
Consider the other case: maybe the hook *needs* to do something even
though the value is not really changing. I haven't got a good example
offhand, but in cache-flush tasks that's not impossible. Or perhaps
more plausible, there may be state not directly visible to GUC that
needs to be checked, even when the displayable var itself is correct
already.
Bottom line: I'd rather require the hooks to be slightly intelligent
than cripple them with a GUC-knows-better-than-they-do policy. The
point of the hooks is to know things that the core GUC code doesn't,
after all.
regards, tom lane