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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers