> I think I may have found another bug: > > WITH RECURSIVE t(i,j) AS ( > VALUES (1,2) > UNION ALL > SELECT t2.i, t.j > FROM ( > SELECT 2 AS i > UNION ALL /* Wrongly getting detected, I think */ > SELECT 3 AS i > ) AS t2 > JOIN > t > ON (t2.i = t.i) > ) > SELECT * FROM t; > ERROR: attribute number 2 exceeds number of columns 1 > > Is there some way to ensure that in the case of WITH RECURSIVE, the > query to the right of UNION ALL follows only the SQL:2008 rules about > not having outer JOINs, etc. in it, but otherwise make it opaque to > the error-checking code? > > I know I didn't explain that well, but the above SQL should work and > the error appears to stem from the parser's looking at the innermost > UNION ALL instead of the outermost.
Here is new patches fixing the bug you pointed out (patches was created by Yoshiyuki). Also I added your SQL to the regression test, and now the patches is against CVS HEAD. For your convenience I also include patches against the previous version. -- Tatsuo Ishii SRA OSS, Inc. Japan
Description: Binary data
*** pgsql/src/backend/executor/nodeAppend.c 2008-08-18 16:20:40.000000000 +0900 --- pgsql.patched/src/backend/executor/nodeAppend.c 2008-08-23 07:37:29.000000000 +0900 *************** *** 143,152 **** --- 143,156 ---- int nplans; int i; Plan *initNode; + TupleDesc save_tupledesc; /* check for unsupported flags */ Assert(!(eflags & EXEC_FLAG_MARK)); + /* Save tuple desc */ + save_tupledesc = estate->es_rscan_tupledesc; + /* * Set up empty vector of subplan states */ *************** *** 232,237 **** --- 236,243 ---- appendstate->as_whichplan = appendstate->as_firstplan; exec_append_initialize_next(appendstate); + /* Restore tuple desc */ + estate->es_rscan_tupledesc = save_tupledesc; + return appendstate; }
-- Sent via pgsql-patches mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches