Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I imagine folks would want it on UPDATE, DELETE, and VACUUM FULL too, > > Why? You can do a SELECT FOR UPDATE first and then you know that you > have the row lock. There's no need for any special handling of UPDATE > or DELETE. I don't see the applicability to VACUUM, either.
Why bother when you can do it without the SELECT FOR UPDATE? > BTW, one idea I was thinking about was that a SELECT FOR UPDATE NOWAIT > behavior might simply not return the rows it couldn't acquire lock on, > instead of erroring out. Not sure if this would be more or less useful > than the error behavior, but I can definitely think of possible > applications for it. > > > Also, I don't see this changing sematics like the regex flavor did. > > You're kidding. This is a much more fundamental change of behavior than No, I am not. > whether some seldom-used regex features work. In particular, we know > that the regex behavior does not affect any other part of the system. > I do not think any equivalent safety claims can be made for random > hacking of whether LockAcquire succeeds or not. It throws an error. I don't see how that could cause actual data corruption or invalid data. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
