Re: Assertions in PL/PgSQL

From: Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assertions in PL/PgSQL
Date: 2013-09-20 10:09:40
Message-ID: CACoZds0KJ_J-AWDhDxmJf0o24teSoLYEB8vn0FVcCQL9df-Cjg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16 September 2013 03:43, Marko Tiikkaja <marko(at)joh(dot)to> wrote:

> On 2013-09-15 23:23, Jaime Casanova wrote:
>
>> If using ASSERT as keyword is not acceptable, not that i agree but in
>> case.
>> What about using RAISE EXCEPTION WHEN (condition)
>>
>
> I was going to suggest the same idea: Extend RAISE syntax without
introducing new keywords. Something like:
RAISE assert_exception WHEN <assert_condition>
... where assert_exception is a new exception label which maps to a new
internal sqlstate.

> I think it would be extremely surprising if a command like that got
> optimized away based on a GUC, so I don't think that would be a good idea.

In pl_gram.y, in the rule stmt_raise, determine that this RAISE is for
ASSERT, and then return NULL if plpgsql_curr_compile->enable_assertions is
false. Isn't this possible ?

>
>
>
> Regards,
> Marko Tiikkaja
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-hackers<http://www.postgresql.org/mailpref/pgsql-hackers>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sameer Thakur 2013-09-20 10:10:31 Re: Patch for fail-back without fresh backup
Previous Message Daniel Farina 2013-09-20 08:31:08 Re: pg_stat_statements: calls under-estimation propagation