Re: WIP: pl/pgsql cleanup

Tom Lane wrote:
> Still a few bricks shy of a load I fear [...]

My apologies; thanks for the code review.

> regression=# create or replace function foo() returns int language plpgsql as $$
> regression$# begin
> regression$#   return ;
> regression$# end$$;
> CREATE FUNCTION
> regression=# select foo();
> server closed the connection unexpectedly
>
> If you're going to stick a NULL into the return's expression then you'd
> better check for same when it's used.

Right. Better I think is to only allow a missing RETURN expression for
functions declared to return void anyway; that catches the mistake at
compile-time. I've implemented this behavior in the revised patch. The
error message in this scenario is still a little poor:

create function missing_return_expr() returns int as $$
begin
     return ;
end;$$ language plpgsql;
ERROR:  syntax error at end of input at character 8
QUERY:  SELECT
CONTEXT:  SQL statement in PL/PgSQL function "missing_return_expr" near
line 2
LINE 1: SELECT
                ^

Is it worth putting in a special-case to look for an unexpected ';' in
either the RETURN production or read_sql_construct() ?

> What I was actually intending to check when I ran into that is why some
> of the error paths in your FOR-loop rewrite use
>     plpgsql_error_lineno = $1;
> while others have
>     plpgsql_error_lineno = plpgsql_scanner_lineno();
> I suspect the former is more appropriate, at least for errors that
> reference the FOR variable and not some other part of the statement.
> Also why the inconsistent use of yyerror() vs ereport()?

Sorry, both of these result from sloppiness on my part: I think the code
was originally correct, but I tried to refactor some of the more complex
parts of the FOR statement production into a separate function, and
eventually wasn't able to (because of the `forvariable' union member).
When I gave up and reverted the code, I obviously wasn't careful enough.

Attached is a revised patch.

-Neil