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