From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: plpgsql - Assert statement |
Date: | 2014-09-05 08:40:32 |
Message-ID: | CAFj8pRAd=rmv91zOqimvq2wYOUPd0yU8OqevzgYGh5KEphmS7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-09-05 10:33 GMT+02:00 Marko Tiikkaja <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
>
> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2014-09-05 08:57:07 | Re: proposal: plpgsql - Assert statement |
Previous Message | Kyotaro HORIGUCHI | 2014-09-05 08:39:35 | Re: Escaping from blocked send() reprised. |