Tom Lane wrote:
=?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.


Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/2952/30706 or +43/664/233 90 75,,

---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?

Reply via email to