Re: proposal: plpgsql - Assert statement

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql - Assert statement
Date: 2014-09-05 08:33:16
Message-ID: 5409754C.1010909@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 [, ... ] ] ];

> 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?).

.marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2014-09-05 08:39:35 Re: Escaping from blocked send() reprised.
Previous Message Kyotaro HORIGUCHI 2014-09-05 08:30:19 Re: Escaping from blocked send() reprised.