Skip site navigation (1) Skip section navigation (2)

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

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rico Wind <rw(at)rico-wind(dot)dk>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1329: Bug in IF-ELSEIF-ELSE construct
Date: 2004-11-29 03:33:55
Message-ID: 1101699235.22124.12.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-patches
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 also
includes an improved version of the "unreachable code" patch that
includes your suggested fixes). Two questions about the patch:

(1) It doesn't report syntax errors in unreachable code. I suppose this
ought to be done, right?

(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 to print the right line number and
query context, but I couldn't get it right. Do you have any guidance on
the proper way to do this.

> 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.)

In the case of dead code checking, I don't think it matters. Doing the
syntax check in gram.y might be a better idea, I'll take a look doing
that...

-Neil


Attachment: plpgsql-unreachable-3.patch
Description: text/x-patch (15.3 KB)

In response to

Responses

pgsql-bugs by date

Next:From: Mehul Doshi-A20614Date: 2004-11-29 08:21:55
Subject: Re: Installation fails for postgresql-8.0.0-beta4 on Windo
Previous:From: Bruce MomjianDate: 2004-11-29 03:17:23
Subject: Re: BUG #1311: Can't crosscompile

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-11-29 03:43:39
Subject: Re: Faster install-sh in C
Previous:From: Bruce MomjianDate: 2004-11-29 03:32:25
Subject: Re: multiline CSV fields

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group