Re: CTE bug?

David Fetter <david@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