Re: Assertions in PL/PgSQL - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Assertions in PL/PgSQL
Date
Msg-id CA+Tgmoaf_yz==3hqmqN-93Tj-H7sUMruXYmG-mq4rH3Ycc_7pg@mail.gmail.com
Whole thread Raw
In response to Re: Assertions in PL/PgSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Assertions in PL/PgSQL  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Assertions in PL/PgSQL  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Sun, Nov 17, 2013 at 5:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> [ rebased patch for RAISE WHEN ]
>
> I have to say I do not see the point of this.  It does nothing you
> can't do already with "IF condition THEN RAISE ...".  And frankly
> the RAISE statement has got too darn many options already.  We don't
> need yet more cruft on it that we'll have to maintain forevermore.
>
> If this were improving standards compliance somehow, I'd be okay
> with it; but what other implementation has got this?

This is a fair point.  I think the goal was to get to RAISE ASSERT
WHEN ...; then, if assertions are off, you do nothing; if they're on,
you error.  IF condition THEN RAISE..." isn't a suitable surrogate in
that case because you incur the overhead of testing the condition
regardless.

Now that having been said, I'm a bit wary of adding every new frammish
someone suggests to PL/pgsql.  Many of the things we've added recently
are things I anticipate that I'll never use.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: better atomics - v0.2
Next
From: Andres Freund
Date:
Subject: Re: better atomics - v0.2