On 23 September 2013 14:33, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> > > > 2013/9/23 Amit Khandekar <amit.khande...@enterprisedb.com> > >> >> >> >> On 23 September 2013 10:10, Pavel Stehule <pavel.steh...@gmail.com>wrote: >> >>> >>> >>> >>> 2013/9/22 Jaime Casanova <ja...@2ndquadrant.com> >>> >>>> >>>> El 21/09/2013 17:16, "Jaime Casanova" <ja...@2ndquadrant.com> escribió: >>>> >>>> > >>>> > On Fri, Sep 20, 2013 at 5:17 AM, Marko Tiikkaja <ma...@joh.to> wrote: >>>> > > On 9/20/13 12:09 PM, Amit Khandekar wrote: >>>> > >> >>>> > >> On 16 September 2013 03:43, Marko Tiikkaja <ma...@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 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 >>>> >>> >>> >> >
