Neil Conway <neilc@samurai.com> 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