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 -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
