Re: reset all update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Marko Kreen <marko(at)l-t(dot)ee>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: reset all update
Date: 2001-06-13 15:45:35
Message-ID: 26646.992447135@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2001-06-13 15:54:28 Re: Patch to include PAM support...
Previous Message Bruce Momjian 2001-06-13 15:35:33 Re: reset all update