Re: plpgsql: RAISE <level> <expr> <params>

"Richard Huxton" <dev(at)archonet(dot)com> writes:
> (For those who haven't looked at that bit of the code recently
> plpgsql_read_expression() slurps up to and including a closing token -
> either a ';' or ',' above. You've then lost that finishing token)

The real problem is that this *isn't* yacc ... if plpgsql had an actual
grammar symbol for "expression" then the change would be trivial.

plpgsql_read_expression is not usable as-is for this purpose, because
"read until token X" is far too simplistic (consider a function call
with two parameters --- the comma between the parameters would be
taken as ending the whole expression).

It might work to add some understanding of nested-parenthesis counting
to the routine; not sure if there are any other shortcomings besides
that one. But in any case, you need to do significant surgery on that
routine, so adding another return parameter shouldn't bother you.

> 4. Alter plpgsql_read_expression() to accept more than one closing token,
> and it stops when it reads any of them.

AFAICT it already stops on ';' (hardwired into the routine). So if you
make it pass back what it stopped on, you're set: the grammar entry
becomes just

stmt_raise : K_RAISE lno raise_level

and then the code takes care of swallowing expressions until ';',
similarly to the way SQL commands are handled. (plpgsql's parsing
methodology is sinfully ugly, isn't it? But I don't suppose you
want to try to replace it...)

regards, tom lane