<p><br /> El 21/09/2013 17:16, "Jaime Casanova" <<a
href="mailto:jaime@2ndquadrant.com">jaime@2ndquadrant.com</a>>escribió:<br /> ><br /> > On Fri, Sep 20, 2013
at5:17 AM, Marko Tiikkaja <<a href="mailto:marko@joh.to">marko@joh.to</a>> wrote:<br /> > > On 9/20/13
12:09PM, Amit Khandekar wrote:<br /> > >><br /> > >> On 16 September 2013 03:43, Marko Tiikkaja
<<ahref="mailto:marko@joh.to">marko@joh.to</a>> wrote:<br /> > >>><br /> > >>> I think it
wouldbe extremely surprising if a command like that got<br /> > >>> optimized away based on a GUC, so I
don'tthink that would be a good<br /> > >>> idea.<br /> > >><br /> > >><br /> >
>><br/> > >> In pl_gram.y, in the rule stmt_raise, determine that this RAISE is for<br /> > >>
ASSERT,and then return NULL if plpgsql_curr_compile->enable_assertions is<br /> > >> false. Isn't this
possible?<br /> > ><br /> > ><br /> > > Of course it's possible. But I, as a PostgreSQL user writing
PL/PgSQLcode,<br /> > > would be extremely surprised if this new cool option to RAISE didn't work<br /> > >
forsome reason. If we use ASSERT the situation is different; most people<br /> > > will realize it's a new
commandand works differently from RAISE.<br /> > ><br /> > ><br /> ><br /> > What about just adding a
clauseWHEN to the RAISE statement and use<br /> > the level machinery (client_min_messages) to make it appear or
not<br/> > of course, this has the disadvantage that an EXCEPTION level will<br /> > always happen... or you can
makeit a new loglevel that mean EXCEPTION<br /> > if asserts_enabled<br /> ><p> meaning RAISE ASSERT of
course<p>--<br/> Jaime Casanova<br /> 2ndQuadrant: Your PostgreSQL partner