Neil Conway <[EMAIL PROTECTED]> writes:
> create function bad_sql1() returns int as $$
> declare a int;
> begin
> a := 5;
> Johnny Yuma;
> a := 10;
> return a;
> end$$ language 'plpgsql';
> ERROR: syntax error at or near "Johnny"
> CONTEXT: SQL statement embedded in PL/PgSQL function "bad_sql1" near
> line 4
That seems like a step backwards from the current behavior:
regression=# create function bad_sql1() returns int as $$
regression$# declare a int;
regression$# begin
regression$# a := 5;
regression$# Johnny Yuma;
regression$# a := 10;
regression$# return a;
regression$# end$$ language 'plpgsql';
CREATE FUNCTION
regression=# select bad_sql1();
ERROR: syntax error at or near "Johnny" at character 1
QUERY: Johnny Yuma
CONTEXT: PL/pgSQL function "bad_sql1" line 4 at SQL statement
LINE 1: Johnny Yuma
^
regression=#
While the difference in information content may not seem great, it is a
big deal when you are talking about a small syntax error in a large SQL
command spanning many lines.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
