As a first step I wanted to add NOWAIT to DELETE:
DELETE FROM ... WHERE ... NOWAIT;
Therefore I used:
/***************************************************************************** * * QUERY: * DELETE STATEMENTS *
*****************************************************************************/
DeleteStmt: DELETE_P FROM relation_expr where_clause opt_nowait
opt_nowait is already defined and used by Tatsuo's LOCK TABLE NOWAIT.
I got ...
[EMAIL PROTECTED] parser]$ bison -y -d -v gram.y conflicts: 6 shift/reduce
... 6 errors:
State 1197 conflicts: 1 shift/reduce State 1198 conflicts: 1 shift/reduce State 1201 conflicts: 1 shift/reduce State 1852 conflicts: 1 shift/reduce State 1853 conflicts: 1 shift/reduce State 1855 conflicts: 1 shift/reduce
...
1196 | BCONST 1197 | XCONST
...
1201 | TRUE_P
...
state 1852
1024 b_expr: b_expr '%' . 1030 | b_expr '%' . b_expr
ABORT_P shift, and go to state 146 ABSOLUTE_P shift, and go to state 147 ACCESS shift, and go to state 148 ACTION shift, and go to state 149
The interesting thing here is - if I change opt_nowait to
DeleteStmt: DELETE_P FROM relation_expr where_clause opt_lock (just for tesing), I still get an error ...
[EMAIL PROTECTED] parser]$ bison -y -d -v gram.y conflicts: 1 shift/reduce
In my understanding of bison DELETE ... WHERE ... IN some_mode MODE; should work ...
Can anybody provide me a fix?
Basically all I wanted to do was SELECT FOR UPDATE NOWAIT, DELETE NOWAIT and UPDATE ... NOWAIT.
The rest of the patch seems to be fairly simple but can anybody lead me out of "parser's hell"?
Best regards,
Hans
---------------------------(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