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 solution would be to just *allow* ELSEIF as a variant spelling of ELSIF. I cannot see any real good argument for not doing that, and considering that we've seen two people make the same mistake in the past month, my interest in doing it is increasing. > (BTW, I think that fixing how we do parsing > would be one of the prime motivations for rewriting PL/PgSQL. Yeah, if we could think of a way. Copying the main grammar a la ecpg is definitely not the way :-( > Alternatively, we could arrange to have the PL/PgSQL parser pass a block > of text it has identified as a possible SQL statement to the main SQL > parser; if it produces a syntax error, we can pass that syntax error > back to the user. I'm not sure if this would have any negative > ramifications, though. 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. 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.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html