Tom Lane wrote:
> Ah, thanks for the simplified test case. This is undoubtedly my fault
> ... will look into it. It is probably somewhat related to the join
> alias problem found yesterday (ie, somebody somewhere is trying to use
> the wrong rangetable list to interpret a Var node).
I spent a bit more time on it last night. Here's an even simpler example:
CREATE TABLE table1 (a int);
CREATE TABLE table2 (a int, b int);
INSERT INTO table1 (a) VALUES (1);
INSERT INTO table2 (a,b) VALUES (1,1);
INSERT INTO table2 (a,b) VALUES (1,2);
CREATE OR REPLACE FUNCTION func1(int) RETURNS setof int AS '
select a from table2 where a = $1
' LANGUAGE 'sql' WITH (isstrict);
CREATE OR REPLACE FUNCTION func2(int,int) RETURNS int AS '
select $1 * $2
' LANGUAGE 'sql' WITH (isstrict);
regression=# SELECT t2.a1 FROM (SELECT func2(t1.f1,3) as a1 FROM (SELECT
func1(1) as f1) AS t1) AS t2 WHERE t2.a1 = 3;
a1
----
3
3
(2 rows)
regression=# EXPLAIN SELECT t2.a1 FROM (SELECT func2(t1.f1,3) as a1 FROM
(SELECT func1(1) as f1) AS t1) AS t2 WHERE t2.a1 = 3;
ERROR: get_names_for_var: bogus varno 2
regression=# EXPLAIN SELECT t2.a1 FROM (SELECT func2(t1.f1,3) as a1 FROM
(SELECT func1(1) as f1) AS t1) AS t2; QUERY
PLAN
----------------------------------------------------
Subquery Scan t1 (cost=0.00..0.01 rows=1 width=0)
-> Result (cost=0.00..0.01 rows=1 width=0)
(2 rows)
The problem is triggered by the WHERE clause. I was struggling as to where to
be looking. BTW, it was still there after I sync'd up with cvs last night.
Joe