David Fetter <da...@fetter.org> writes: > WITH RECURSIVE t(j) AS ( > WITH RECURSIVE s(i) AS ( > VALUES (1) > UNION ALL > SELECT i+1 FROM s WHERE i < 10 > ) SELECT i AS j FROM s > UNION ALL > SELECT j+1 FROM t WHERE j < 10 > ) > SELECT * FROM t; > ERROR: relation "s" does not exist > LINE 6: ) SELECT i AS j FROM s > ^ > Shouldn't this work?
Huh, nice test case. It looks like it's trying to do the "throwaway parse analysis" of the nonrecursive term (around line 200 of parse_cte.c) without having analyzed the inner WITH clause. We could probably fix it by doing a throwaway analysis of the inner WITH too ... but ... that whole throwaway thing is pretty ugly and objectionable from a performance standpoint anyhow. I wonder if it wouldn't be better to refactor so that transformSetOperationStmt knows when it's dealing with the body of a recursive UNION and does the analyzeCTETargetList business after having processed the first UNION arm. This would inject a bit more coupling between transformSetOperationStmt and the CTE code than is there now, but it seems to me that if anything it's a less surprising implementation. If you were looking to find where the output column types of a recursive union got determined, you'd expect to find it somewhere near the UNION code, no? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers