Re: [HACKERS] new "row-level lock" error messages

2013-08-01 Thread Alvaro Herrera
Robert Haas escribió: > The fact that there are no tests of this functionality is probably not > a good thing. We should add some. At the moment, the following test > case crashes, and it looks like this commit is responsible: > > create table test_update2 (id integer); > DECLARE test_update_cu

Re: [HACKERS] new "row-level lock" error messages

2013-08-01 Thread Alvaro Herrera
Robert Haas escribió: > The fact that there are no tests of this functionality is probably not > a good thing. We should add some. No disagreement. > At the moment, the following test > case crashes, and it looks like this commit is responsible: > > create table test_update2 (id integer); > DE

Re: [HACKERS] new "row-level lock" error messages

2013-08-01 Thread Robert Haas
On Tue, Jul 23, 2013 at 2:16 PM, Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Peter Eisentraut wrote: >> >> > I would suggest that these changes be undone, except that the old >> > "SELECT FOR ..." be replaced by a dynamic string that reverse-parses the >> > LockingClause to provide the actual

Re: [HACKERS] new "row-level lock" error messages

2013-07-23 Thread Alvaro Herrera
Alvaro Herrera wrote: > Peter Eisentraut wrote: > > > I would suggest that these changes be undone, except that the old > > "SELECT FOR ..." be replaced by a dynamic string that reverse-parses the > > LockingClause to provide the actual clause that was used. > > Here's a patch for this. Pushed t

Re: [HACKERS] new "row-level lock" error messages

2013-07-22 Thread Alvaro Herrera
Peter Eisentraut wrote: > I would suggest that these changes be undone, except that the old > "SELECT FOR ..." be replaced by a dynamic string that reverse-parses the > LockingClause to provide the actual clause that was used. Here's a patch for this. -- Álvaro Herrerahttp://www

Re: [HACKERS] new "row-level lock" error messages

2013-07-17 Thread Alvaro Herrera
Peter Eisentraut wrote: > In general, I find these new wordings to be a loss of clarity. There is > no indication on the SELECT man page or in the documentation index what > a "row-level lock" is at all. > > I would suggest that these changes be undone, except that the old > "SELECT FOR ..." be

[HACKERS] new "row-level lock" error messages

2013-07-15 Thread Peter Eisentraut
In 9af4159f in combination with cb9b66d3 a bunch of error messages were changed from something like "SELECT FOR UPDATE/SHARE is not allowed with UNION/INTERSECT/EXCEPT" to "row-level locks are not allowed with UNION/INTERSECT/EXCEPT" because the intermediate state of "SELECT FOR UPDATE/SHARE/K