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
Neil Conway <[EMAIL PROTECTED]> writes:
> (2) The syntax error message is wrong (we print a character offset and
> query context that is relative to the CREATE FUNCTION statement, not the
> individual SQL statement we're executing). I fooled around a bit with
> defining a custom ereport() callback
On Sat, 2004-11-27 at 12:55 -0500, Tom Lane wrote:
> This seems like the most appropriate answer to me; I was thinking of
> doing that earlier when Fabien and I were fooling with plpgsql error
> reporting, but didn't get around to it.
Attached is a patch that implements a rough draft of this (it a
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There is no ELSEIF construct.
> Sure, but it would be nice to throw a syntax error rather than silently
> accepting the function. Unfortunately the way PL/PgSQL's parser works
> doesn't make this very easy.
Actually, the simplest solu
Tom Lane wrote:
There is no ELSEIF construct.
Sure, but it would be nice to throw a syntax error rather than silently
accepting the function. Unfortunately the way PL/PgSQL's parser works
doesn't make this very easy. (BTW, I think that fixing how we do parsing
would be one of the prime motivatio
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Description:Bug in IF-ELSEIF-ELSE construct
There is no ELSEIF construct. Try ELSIF.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmas
The following bug has been logged online:
Bug reference: 1329
Logged by: Rico Wind
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 Beta
Operating system: Windows XP, SP2
Description:Bug in IF-ELSEIF-ELSE construct
Details:
Beta 1.
The following always
