Re: proposal: plpgsql - Assert statement

On 09/05/2014 04:40 AM, Pavel Stehule wrote:
>
>
>
> 2014-09-05 10:33 GMT+02:00 Marko Tiikkaja <marko@joh.to
> <mailto:marko@joh.to>>:
>
>     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 [, ... ] ] ];
>
>
> 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;


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


-- 
Jan Wieck
Senior Software Engineer
http://slony.info