Re: proposal: plpgsql - Assert statement

From: Jan Wieck <jan(at)wi3ck(dot)info>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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 12:35:11
Message-ID: 5409ADFF.90203@wi3ck.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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;

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Geoff Montee 2014-09-05 12:54:41 Re: A mechanism securing web applications in DBMS
Previous Message Amit Kapila 2014-09-05 11:50:29 Re: Scaling shared buffer eviction