Re: proposal: plpgsql - Assert statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql - Assert statement
Date: 2014-11-19 17:01:14
Message-ID: 28833.1416416474@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Nov 19, 2014 at 11:13 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> FWIW, I would vote against it also. I do not find this to be a natural
>> extension of RAISE; it adds all sorts of semantic issues. (In particular,
>> what is the evaluation order of the WHEN versus the other subexpressions
>> of the RAISE?)

> What I liked about this syntax was that we could eventually have:
> RAISE ASSERT WHEN stuff;
> ...and if assertions are disabled, we can skip evaluating the
> condition. If you just write an IF .. THEN block you can't do that.

Well, if that's what you want, let's just invent

ASSERT condition

and not tangle RAISE into it. The analogy to EXIT WHEN is a lot
cleaner in this form: no order-of-evaluation issues, no questions
of whether a sub-clause results in totally changing the meaning
of the command. And if your argument is partially based on
how much you have to type, doesn't this way dominate all others?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-19 17:03:17 Re: What exactly is our CRC algorithm?
Previous Message Robert Haas 2014-11-19 16:49:40 Re: What exactly is our CRC algorithm?