=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
The problem with adding NO WAIT to specific commands is that is inheritly unflexible. I think this is why the community has agreed on implementing it based on GUC.
I recall no such agreement ... when was this exactly? In any case Bruce's recent complaints about regex_flavor have altered my opinions about GUC variables a bit. They are bigger safety risks than they look, especially ones that change semantics and are intended to be modified on the fly.
I thought there was an agreement because the GUC version is on the TODO list. Anyway ...
Do you think it would help to reduce the GUCs flexibility by reducing the lock levels a user is allowed to define?
I will vote against the patch no matter what, but I agree that it would be less dangerous if it were confined to only apply to a limited set of lock types.
regards, tom lane
I think we should compromise.
We can restrict it to locks which are high enough or higher to make SELECT FOR UPDATE work.
Of course it would have been nice to have full flexibility but I think we can have almost the same benefit for lower risk.
How about it? Tom, Bruce - which types of locks do we allow?
I will change the patch then.
Maybe this is the best solution.
Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?