From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CTE bug? |
Date: | 2009-09-08 22:11:43 |
Message-ID: | 17204.1252447903@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Fetter <david(at)fetter(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | decibel | 2009-09-08 22:15:31 | Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic) |
Previous Message | Robert Creager | 2009-09-08 21:29:29 | Any interest in buildfarm a member using Apple's llvm-gcc-4.2 or clang? |