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.