Re: Assertions in PL/PgSQL

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

On 23 September 2013 14:33, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

>
>
>
> 2013/9/23 Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com>
>
>>
>>
>>
>> On 23 September 2013 10:10, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:
>>
>>>
>>>
>>>
>>> 2013/9/22 Jaime Casanova <jaime(at)2ndquadrant(dot)com>
>>>
>>>>
>>>> El 21/09/2013 17:16, "Jaime Casanova" <jaime(at)2ndquadrant(dot)com> escribió:
>>>>
>>>> >
>>>> > On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
>>>> > > On 9/20/13 12:09 PM, Amit Khandekar wrote:
>>>> > >>
>>>> > >> On 16 September 2013 03:43, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
>>>> > >>>
>>>> > >>> 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 ?
>>>> > >
>>>> > >
>>>> > > Of course it's possible. But I, as a PostgreSQL user writing
>>>> PL/PgSQL code,
>>>> > > would be extremely surprised if this new cool option to RAISE
>>>> didn't work
>>>> > > for some reason. If we use ASSERT the situation is different; most
>>>> people
>>>> > > will realize it's a new command and works differently from RAISE.
>>>> > >
>>>> > >
>>>> >
>>>> > What about just adding a clause WHEN to the RAISE statement and use
>>>> > the level machinery (client_min_messages) to make it appear or not
>>>> > of course, this has the disadvantage that an EXCEPTION level will
>>>> > always happen... or you can make it a new loglevel that mean EXCEPTION
>>>> > if asserts_enabled
>>>> >
>>>>
>>>> meaning RAISE ASSERT of course
>>>>
>>>
>>> After days I am thinking so it can be a good solution
>>>
>>> syntax - enhanced current RAISE
>>>
>>> RAISE ASSERT WHEN boolean expression
>>>
>>> RAISE ASSERT 'some message' WHEN expression
>>>
>>> and we can have a GUC that controls asserts per database - possibly
>>> overwritten by plpgsql option - similar to current plpgsql options
>>>
>>> assert_level = [*ignore*, notice, warning, error]
>>>
>>
>> The assert levels sound a bit like a user might be confused by these
>> levels being present at both places: In the RAISE syntax itself, and the
>> assert GUC level. But I like the syntax. How about keeping the ASSERT
>> keyword optional ? When we have WHEN, we anyway mean that we ware asserting
>> that this condition must be true. So something like this :
>>
>> RAISE [ level ] 'format' [, expression [, ... ]] [ USING option =
>> expression [, ... ] ];
>> RAISE [ level ] condition_name [ USING option = expression [, ... ] ];
>> RAISE [ level ] SQLSTATE 'sqlstate' [ USING option = expression [, ... ]
>> ];
>> RAISE [ level ] USING option = expression [, ... ];
>> *RAISE [ ASSERT ] WHEN bool_expression;*
>> RAISE ;
>>
>>
> I don't think so it is a good idea. WHEN clause should be independent on
> exception level.
>

I am ok with generalizing the WHEN clause across all levels. The main
proposal was for adding assertion support, so we can keep the WHEN
generalization as a nice-to-have stuff and do it only if it comes as a
natural extension in the assertion support patch.

>
> Pavel
>
>
>
>>
>>
>>> comments?
>>>
>>> Regards
>>>
>>> Pavel
>>>
>>> p.s. clause WHEN can be used for other exception level - so it can be a
>>> interesting shortcut for other use cases.
>>>
>>> --
>>>> Jaime Casanova
>>>> 2ndQuadrant: Your PostgreSQL partner
>>>>
>>>
>>>
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-09-23 11:41:16 Re: all_visible replay aborting due to uninitialized pages
Previous Message Pavel Stehule 2013-09-23 09:16:13 Re: Assertions in PL/PgSQL