From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/pgsSQL EXECUTE USING INTO |
Date: | 2010-08-19 16:52:49 |
Message-ID: | 16328.1282236769@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> While testing the recent issue with unknown params in EXECUTE USING, I
> accidentally did this:
> EXECUTE 'SELECT ''foo'' || $1' USING 'bar' INTO t;
> The mistake I made? I put the USING and INTO clauses in wrong order,
> INTO needs to go first. We should throw an error on that, but it looks
> like the INTO clause is just silently ignored.
This is more interesting than it looks. It appears that the plpgsql
parser interprets the USING's argument expression as being
'bar' INTO t
so it generates a plplgsql expression with query
SELECT 'bar' INTO t
and the only reason that you don't get a failure is that
exec_simple_check_plan fails to notice the intoClause, so it thinks
this represents a "simple expression", which means it evaluates the
'bar' subexpression and ignores the INTO altogether. That's
certainly a bug in exec_simple_check_plan :-(
I think that accepting this order of the clauses would require some
duplication of code in the stmt_dynexecute production. It might be
worth doing anyway, because if you made this mistake then certainly
others will.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-08-19 16:56:54 | Re: Re: [COMMITTERS] pgsql: Coerce 'unknown' type parameters to the right type in the |
Previous Message | Robert Haas | 2010-08-19 16:49:45 | Re: wip: functions median and percentile |