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