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
