Re: proposal: plpgsql - Assert statement

2014-09-05 14:35 GMT+02:00 Jan Wieck <jan(at)wi3ck(dot)info>:

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

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
>>
>>
>>
>> .marko
>>
>>
>>
>
> --
> Jan Wieck
> Senior Software Engineer
> http://slony.info
>