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 -- Jaime Casanova 2ndQuadrant: Your PostgreSQL partner
