Re: Assertions in PL/PgSQL
От | Jaime Casanova |
---|---|
Тема | Re: Assertions in PL/PgSQL |
Дата | |
Msg-id | CAJKUy5ier7cXMVnwjqmQUC5YgM2K_h198i_2PwD-1PZDtvo5sg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Assertions in PL/PgSQL (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: Assertions in PL/PgSQL
|
Список | pgsql-hackers |
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 -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte 24x7 y capacitación Phone: +593 4 5107566 Cell: +593 987171157
В списке pgsql-hackers по дате отправления: