Re: Assertions in PL/PgSQL - Mailing list pgsql-hackers

On 9/19/13 7:08 AM, Pavel Stehule wrote:
>     FWIW, we've written a framework (currently available in the EnovaTools project on pgFoundry) that allows for
very,very fine-grain control over asserts.
 
>
>     - Every assert has a name (and an optional sub-name) as well as a level
>     - You can globally set the minimum level that will trigger an assert. This is useful for some debugging stuff;
havean assert with a negative level and normally it won't fire unless you set the minimum level to be less than zero.
 
>     - You can disable an assert globally (across all backends)
>     - You can disable an assert only within your session
>
>     We should eventually allow for disabling an assert only for your transaction; we just haven't gotten around to it
yet.
>
>     The reason for all this flexibility is the concept of "it should be very difficult but not impossible for the
codeto do X". We use it for sanity-checking things.
 
>
>
> I think so similar frameworks will be exists (we have some similar functionality) in orafce too - and it is not
reasonwhy we should not merge some function to core. I am with Marko, so some simple, user friendly statement for
assertionsshould be very nice plpgsql feature. I am different in opinion how to implementat it and about syntax. I
prefera possibility (not necessary currently implemented) to enhance this feature for similar tasks (as buildin or
externalfeature)
 
>
> Probably You and me have a same opinion so only simple and very primitive assert is not enough:
>
> I see as useful feature for assertions:
>
> a) possibility to specify a message (two parametric assert)
> b) possibility to specify some threshold
> c) possibility to specify some level (exception, warning, notice) .. default should be exception
> c) possibility to specify a handled/unhandled exception

I'm not opposed to the improvements you're proposing, but I do want to point out that none of them would allow us to
usethese asserts, because we definitely need the ability to enable and disable individual asserts.
 

(Understand that what we've developed is actually rather different from the C concept of asserts...)

I'm not saying that's necessarily bad, but there is an interesting point here: different environments might have
radicallydifferent needs for dealing with asserts that fail.
 

What we *could* make use of would be asserts that are extremely fast when the assert passes but then allow us to do
whateverwe want when an assert fails (including possibly ignoring the fact that the assert failed).
 

Of course, if the community wanted to just accept the API and functionality we've developed I'd be fine with that
too...;P
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net