| From: | Marko Tiikkaja <marko(at)joh(dot)to> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: plpgsql - Assert statement |
| Date: | 2014-11-26 12:31:37 |
| Message-ID: | 5475C829.2050807@joh.to |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> * 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".
.marko
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2014-11-26 12:34:12 | Re: Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries |
| Previous Message | Pavel Stehule | 2014-11-26 11:41:41 | Re: [pgsql-packagers] Palle Girgensohn's ICU patch |