On 9/5/14 10:09 AM, Pavel Stehule wrote:
I think this could still be parsed correctly, though I'm not 100% sure on
that:
ASSERT WARNING (EXISTS(SELECT ..)), 'data are there';
PLpgSQL uses a ';' or some plpgsql keyword as SQL statement delimiter. It
reason why RETURN QUERY ... ';' So in this case can practical to place SQL
statement on the end of plpgsql statement.
*shrug* There are lots of cases where a comma is used as well, e.g.
RAISE NOTICE '..', <expr>, <expr>;
parenthesis are not practical, because it is hard to identify bug ..
I don't see why. The PL/PgSQL SQL parser goes to great lengths to
identify unmatched parenthesis. But the parens probably aren't
necessary in the first place; you could just omit them and keep parsing
until the next comma AFAICT. So the syntax would be:
RAISE [ NOTICE | WARNING | EXCEPTION/ASSERT/WHATEVER ]
boolean_expr [, error_message [, error_message_param [, ... ] ] ];
A simplicity of integration SQL and PLpgSQL is in using "smart" keywords -
It is more verbose, and it allow to well diagnostics
I disagree. The new keywords provide nothing of value here. They even
encourage the use of quirky syntax in *exchange* for verbosity ("IS NOT
NULL pk"? really?).
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
