On 2011-12-13 18:34, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> writes:
Attached is a patch with those changes. I also I removed a few of the
syntax error regression tests, that seemed excessive, plus some general
naming and comment fiddling. I'll apply this tomorrow, if it still looks
good to me after sleeping on it.
However, I'm still concerned about whether this approach gives
reasonable error messages in cases where the error would be
detected during parse analysis of the rearranged statement.
The regression test examples don't cover such cases, and I'm
too busy right now to apply the patch and check for myself.
What happens for example if a named parameter's value contains
a misspelled variable reference, or a type conflict?
I tested this and seems to be ok:
regression=# select namedparmcursor_test1(20000, 20000) as "Should be
false",
namedparmcursor_test1(20, 20) as "Should be true";
ERROR: column "yy" does not exist
LINE 1: SELECT x AS param1, yy AS param12;
regression=# select namedparmcursor_test1(20000, 20000) as "Should be
false",
namedparmcursor_test1(20, 20) as "Should be true";
ERROR: invalid input syntax for integer: "2011-11-29 19:26:10.029084"
CONTEXT: PL/pgSQL function "namedparmcursor_test1" line 8 at OPEN
regards,
Yeb Havinga
last error was created with
create or replace function namedparmcursor_test1(int, int) returns
boolean as $$
declare
c1 cursor (param1 int, param12 int) for select * from rc_test where
a > param1 and b > param12;
y int := 10;
x timestamp := now();
nonsense record;
begin
open c1(param12 := $1, param1 := x);
end
$$ language plpgsql;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
