Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Robert Haas <robertmhaas@gmail.com> writes:
> I kinda agree with this.  I believe Tom was arguing upthread that any
> change of this short should touch all of the places where NOWAIT is
> accepted now, and I agree with that.  But having to issue SET as a
> separate statement and then maybe do another SET afterward to get the
> old value back doesn't seem like it provides any real advantage.  GUCs
> are good for properties that you want to set and leave set, not so
> good for things that are associated with particular statements.

My point is that I don't believe the scenario where you say that you
know exactly how long each different statement in your application
should wait and they should all be different.  What I do find credible
is that you want to set a "policy" for all the lock timeouts.  Now
think about what happens when it's time to change the policy.  A GUC
is gonna be a lot easier to manage than timeouts that are embedded in
all your individual queries.

> It also seems to me that there's no reason for NOWAIT to be part of
> the syntax, but WAIT n to be a GUC.

I wasn't happy about NOWAIT in the syntax, either ;-) ... but at least
that's a boolean and not a parameter whose specific value was plucked
out of thin air, which is what it's pretty much always going to be.

			regards, tom lane