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>
>
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 |