Re: proposal: plpgsql - Assert statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql - Assert statement
Date
Msg-id CAFj8pRD=VpK2Nm1bMhCLkFJc9V3gK+zw+S6TK7mM0-G9rohhgw@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql - Assert statement  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: proposal: plpgsql - Assert statement  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers


2014-11-18 10:23 GMT+01:00 Simon Riggs <simon@2ndquadrant.com>:
On 18 November 2014 01:00, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 11/17/14, 4:58 PM, Simon Riggs wrote:
>>>>
>>>> Great, looks good to me, marking as ready for committer.
>>
>>
>> What is wrong with using IF ?
>
>
> It's a hell of a lot wordier. I've previously created a more sophisticated
> "assert" framework to allow more control over things, but ended up also
> using it just for simple sanity checking because it was much nicer than
> typeing IF THEN RAISE ERROR END IF.

Why is that not a requirement for a less wordier form of IF?

IF (something) THEN action

statement IF is a control statement - and syntax, pattern for control statements in plpgsql is consistent. I don't want to break it (more, probably it is hardly implemented due problems in bison). PL/pgSQL, PL/SQL, Ada are well designed (in my opinion). Conditional statement has precedent in PL/pgSQL now. We support EXIT and CONTINUE WHEN, so we don't propose a new pattern, only reuse some existing.

Regards

Pavel


 

Why is this problem specific to RAISE?


--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [TODO] Track number of files ready to be archived in pg_stat_archiver
Next
From: Amit Kapila
Date:
Subject: Re: alternative model for handling locking in parallel groups