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:
extension RAISE about ASSERT level has minimal new value
Adding a WHEN clause to RAISE would have the benefit of not needing any new keywords at all.
RAISE EXCEPTION 'format' [, expr ...] WHEN row_count <> 1;
It was one my older proposal.
Can we find a agreement there?
Pavel
Regards, Jan
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?).
It is about semantic and conformity of proposed tools. Sure, all can reduced to ASSERT(expr) .. but where is some benefit against function call
I am able to do without any change of language as plpgsql extension - there is no necessary to do any change for too thin proposal
