Re: Assertions in PL/PgSQL - Mailing list pgsql-hackers
From | Amit Khandekar |
---|---|
Subject | Re: Assertions in PL/PgSQL |
Date | |
Msg-id | CACoZds19DsLErA7zkyjjo00vv4gD92zrh9F3HCTXdFbLiUwYvA@mail.gmail.com Whole thread Raw |
In response to | Re: Assertions in PL/PgSQL (Pavel Stehule <pavel.stehule@gmail.com>) |
Responses |
Re: Assertions in PL/PgSQL
|
List | pgsql-hackers |
On 23 September 2013 14:33, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2013/9/23 Amit Khandekar <amit.khandekar@enterprisedb.com>On 23 September 2013 10:10, Pavel Stehule <pavel.stehule@gmail.com> wrote:2013/9/22 Jaime Casanova <jaime@2ndquadrant.com>
El 21/09/2013 17:16, "Jaime Casanova" <jaime@2ndquadrant.com> escribió:
>
> On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja <marko@joh.to> wrote:
> > On 9/20/13 12:09 PM, Amit Khandekar wrote:
> >>
> >> On 16 September 2013 03:43, Marko Tiikkaja <marko@joh.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 solutionsyntax - enhanced current RAISERAISE ASSERT WHEN boolean expressionRAISE ASSERT 'some message' WHEN expressionand we can have a GUC that controls asserts per database - possibly overwritten by plpgsql option - similar to current plpgsql optionsassert_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?RegardsPavelp.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
pgsql-hackers by date: