Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group