CREATE RULE syntax simplification - Mailing list pgsql-hackers

There are a couple of gripes in the pgsql-sql list this morning about
being unable to enter CREATE RULE commands that specify multiple
actions --- those folk are getting parser: parse error at or near ""
from what appears to be perfectly valid syntax.  I suppose they are
getting burnt by a broken vendor-supplied yacc.  But while looking at
this, I couldn't help noticing how crufty the syntax is:

RuleActionList:  NOTHING                { $$ = NIL; }       | SelectStmt                    { $$ = lcons($1, NIL); }
  | RuleActionStmt                { $$ = lcons($1, NIL); }       | '[' RuleActionBlock ']'       { $$ = $2; }       |
'('RuleActionBlock ')'       { $$ = $2; }        ;
 

RuleActionBlock:  RuleActionMulti       {  $$ = $1; }       | RuleActionStmt                { $$ = lcons($1, NIL); }
  ;
 

RuleActionMulti:  RuleActionMulti RuleActionStmt               {  $$ = lappend($1, $2); }       | RuleActionMulti
RuleActionStmt';'               {  $$ = lappend($1, $2); }       | RuleActionStmt ';'               { $$ = lcons($1,
NIL);}       ;
 

RuleActionStmt: InsertStmt       | UpdateStmt       | DeleteStmt       | NotifyStmt       ;

What's wrong with that you say?  Well, it allows a RuleActionBlock to
be made up of RuleActionStmts that aren't separated by semicolons.
Specifically    stmt1 ; stmt2 stmt3 stmt4
has a production sequence.

I don't know if that was intentional or not, but it sure looks like
a shift/reduce conflict waiting to happen, as soon as the possible
RuleActionStmts get any more complicated.  In any case, it's pretty
bizarre that a semi is only required after the first statement.

I suggest that we require separating semicolons and simplify the
RuleActionBlock production to a more conventional list style,

RuleActionBlock:  RuleActionStmt    | RuleActionBlock ';' RuleActionStmt    | RuleActionBlock ';'

(the last alternative isn't normal list style, but it allows a trailing
semicolon which is accepted by the existing grammar).

Aside from forestalling future trouble with syntax extensions, this
might make us work a little better with old versions of yacc.  I don't
know exactly why this area is a trouble spot for vendor yaccs, but it
seems to be.  Simplifying the syntax may well help.

Comments?  Anyone really in love with semicolon-less rule lists?
        regards, tom lane