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