Hello
>
>> Also, what kind of report does this generate?
>
> Good question. I suspect what Pavel has now will raise errors, but that
> doesn't scale very nicely to checking more than one function, or even to
> finding more than one bug in a single function.
>
I stop on first error now. Reason is reuse of functionality that can
to mark a critical point (bug) of embedded query in console.
Continuous checking is possible (plpgsql), but there are a few
critical bugs, that does stop. For example - any buggy assign to
record var causes uninitialized variable and any later checks are
affected. This is possible when ASSIGN, FOR SELECT, SELECT INTO
statements are used. It is small part of possible bugs but relative
often pattern. So I didn't worry about it yet.
> My first instinct is to say that it should work like plain EXPLAIN, ie,
> deliver a textual report that we send as if it were a query result.
>
can be - but EXPLAIN raises exception too, when there some error.
There should be a some possibility to simply identify result. I am not
sure if checking on empty result is good way. A raising exception
should be option. When we return text, then we have to think about
some structured form result - line, position, message. A advance of
exception on first issue is fact, so these questions are solved.
so CHECK can returns lines - like EXPLAIN, but can be nice and helpful
for this moment a GUC - some like check_raises_exception = on|off.
Default should be "off". And I have to think about some FORMAT option.
is it good plan?
Pavel
> regards, tom lane