2013/9/18 Jim Nasby <j...@nasby.net> > On 9/14/13 11:55 PM, Pavel Stehule wrote: > >> >> >> >> 2013/9/15 Marko Tiikkaja <ma...@joh.to <mailto:ma...@joh.to>> >> >> >> On 2013-09-15 00:09, Pavel Stehule wrote: >> >> this is a possibility for introduction a new hook and possibility >> implement >> asserions and similar task in generic form (as extension). it can >> be >> assertions, tracing, profiling. >> >> >> You can already do tracing and profiling in an extension. I don't >> see what you would put inside the function body for these two, either. >> >> >> you cannot mark a tracing points explicitly in current (unsupported now) >> extensions. >> >> These functions share same pattern: >> >> CREATE OR REPLACE FUNCTION assert(boolean) >> RETURNS void AS $$ >> IF current_setting('plpgsq.**assertions') = 'on' THEN >> IF $1 THEN >> RAISE EXCEPTION 'Assert fails'; >> END IF; >> END IF; >> END; >> $$ LANGUAGE plpgsql; >> >> CREATE OR REPLACE FUNCTION trace(text) >> RETURNS void AS $$ >> IF current_setting('plpgsq.trace'**) = 'on' THEN >> RAISE WARNING 'trace: %', $1; END IF; >> END; >> $$ LANGUAGE plpgsql; >> >> Depends on usage, these functions will not be extremely slow against to >> builtin solution - can be faster, if we implement it in C, and little bit >> faster if we implement it as internal PLpgSQL statement. But if you use a >> one not simple queries, then overhead is not significant (probably). >> >> You have to watch some global state variable and then execute (or not) >> some functionality. >> > > 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; have an 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 code to 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 reason why we should not merge some function to core. I am with Marko, so some simple, user friendly statement for assertions should be very nice plpgsql feature. I am different in opinion how to implementat it and about syntax. I prefer a possibility (not necessary currently implemented) to enhance this feature for similar tasks (as buildin or external feature) 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 Regards Pavel > -- > Jim C. Nasby, Data Architect j...@nasby.net > 512.569.9461 (cell) http://jim.nasby.net >
