Re: BUG #1329: Bug in IF-ELSEIF-ELSE construct

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