Hello
2013/9/18 Marko Tiikkaja <ma...@joh.to> > On 2013-09-16 21:24, Pavel Stehule wrote: > >> 2. a failed assert should to raise a exception, that should not be handled >> by any exception handler - similar to ERRCODE_QUERY_CANCELED - see >> exception_matches_conditions. >> > > I'm not sure what I think about that idea. I see decent arguments for it > working either way. Care to unravel yours a bit more? > yes so CREATE OR REPLACE FUNCTION foo(a int) RETURNS int BEGIN ASSERT a BETWEEN 1 AND 100; RETURNS a; END; $$ LANGUAGE plpgsql; CREATE OR REPLACE FUNCTION proc() RETURNS int AS $$ BEGIN do some complex logic that exec a foo function EXCEPTION WHEN OTHERS THEN -- log some errors INSERT INTO log VALUES(...) END; $$ LANGUAGE plpgsql; In this code a assert fail can be lost in app log. Or can be knowingly handled and ignored - what is wrong, and should not be allowed. When I wrote a little bit complex procedures, I had to use a EXCEPTION WHEN OTHERS clause - because I would not to lost a transaction. It worked, but searching a syntax errors was significantly harder - so on base of this experience I am thinking so some errors can be handled (related to database usage) and others not - like syntax errors in PL/pgSQL or possible assertions (although we can handle syntax error, but I don't think so it is practical). It significantly increase a work that is necessary for error identification. Regards Pavel > > > Regards, > Marko Tiikkaja >
