Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
