Re: BUG #1329: Bug in IF-ELSEIF-ELSE construct - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #1329: Bug in IF-ELSEIF-ELSE construct
Date
Msg-id 24631.1103655451@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #1329: Bug in IF-ELSEIF-ELSE construct  (Neil Conway <neilc@samurai.com>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: j6m@cvni.net
Date:
Subject: Re: Polymorphism resgression test fails when BLCKSZ changed
Next
From: "Magnus Hagander"
Date:
Subject: Re: [pgsql-www] BUG #1355: 8.0.0 rc2 installer fails