Awhile back I wrote: >> As long as you only do this in check_function_bodies mode it seems >> safe enough. One possible problem (if it's done towards the end of >> parsing as you've suggested for dead-code checking) is that a syntax >> error in a SQL statement might confuse the plpgsql parser into >> misparsing statement boundaries, which could lead to a plpgsql parse >> error much further down, such as a "missing END" at the end of the >> function. The error would be more useful if reported immediately >> after the putative SQL statement is parsed. Not sure if that's >> hard or not. (The same remark applies to dead code checking, now >> that I think about it.)
A real-world example of why this would be useful can be seen at http://archives.postgresql.org/pgsql-novice/2004-12/msg00223.php The problem is a missing semicolon just before an IF construct. If the putative PERFORM were SQL-parsed right away, the user could see what had been taken as the body of the PERFORM and would be able to figure out his mistake. If we continue plpgsql-parsing it's very hard to see how we avoid generating an error that leads the user to look in the wrong place. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
