Re: proposal: plpgsql - Assert statement - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: plpgsql - Assert statement
Date
Msg-id CAFj8pRDbB0O4Dgjg=i_ZSgbchPLpRUffGM0KzS9bCqa37HGidg@mail.gmail.com
Whole thread Raw
In response to Re: proposal: plpgsql - Assert statement  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal: plpgsql - Assert statement  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hi

any comments to last proposal and patch?

Pavel

2014-11-26 19:52 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
Hi

2014-11-26 16:46 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:


2014-11-26 13:31 GMT+01:00 Marko Tiikkaja <marko@joh.to>:
On 11/26/14 8:55 AM, Pavel Stehule wrote:
* should be assertions globally enabled/disabled? - I have no personal
preference in this question.

I think so.  The way I would use this function is to put expensive checks into strategic locations which would only run when developing locally (and additionally perhaps in one of the test environments.)  And in that case I'd like to globally disable them for the live environment.

ok
 

* can be ASSERT exception handled ? - I prefer this be unhandled exception
- like query_canceled because It should not be masked by plpgsql EXCEPTION
WHEN OTHERS ...

I don't care much either way, as long as we get good information about what went wrong.  A stack trace and hopefully something like print_strict_params for parameters to the "expr".

There is more ways, I can live with both

here is proof concept

what do you think about it?

Regards

Pavel
 

Pavel

 


.marko


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Confusing comment in tidbitmap.c
Next
From: Mark Cave-Ayland
Date:
Subject: Re: Commitfest problems