Interesting parsing problem ...

I am willing to add NOWAIT to a couple of commands and I have tried to 
resolve a bison problem for quite some time now:

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 ...

[hs@athlon 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 ...


[hs@athlon 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