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

From Pavel Stehule
Subject Re: Assertions in PL/PgSQL
Date
Msg-id CAFj8pRAoO=JmS+D30BK6j1PrVR04oaXDHYa9PO7PQY7zsbuSTA@mail.gmail.com
Whole thread
In response to Re: Assertions in PL/PgSQL  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers



2013/11/27 Peter Eisentraut <peter_e@gmx.net>
On Tue, 2013-11-19 at 10:40 -0500, Robert Haas wrote:
> 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.

So if I do RAISE ASSERT WHEN condition and assertions are off, then
condition wouldn't even be evaluated?  But what about RAISE NOTICE WHEN,
when log_min_messages is error?  What about the side effects of the
format string?  This is all just getting too weird.

I don't see anything wrong with considering a separate ASSERT command
with its own semantics, like in many other programming languages.


My objection against ASSERT command was one - it was too simply (against to cost of possible collision from introduction new (wide used) keyword.

I can live with ASSERT statement - but I expect as minimum a possibility to specify level (failure, tracing, ...) and specify a message related to assert. Assert with only expression is not enough.

Regards

Pavel

pgsql-hackers by date:

Previous
From: mohsen soodkhah mohammadi
Date:
Subject: Name type in postgres
Next
From: Shigeru Hanada
Date:
Subject: Re: Status of FDW pushdowns