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

Reply via email to