Re: Possible Bug in 9.2beta3 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Possible Bug in 9.2beta3
Date
Msg-id 8039.1345049624@sss.pgh.pa.us
Whole thread Raw
In response to Possible Bug in 9.2beta3  (Adam Mackler <AdamMackler@gmail.com>)
Responses Re: Possible Bug in 9.2beta3  (Adam Mackler <adammackler@gmail.com>)
List pgsql-bugs
Adam Mackler <AdamMackler@gmail.com> writes:
> WITH RECURSIVE
> tab(id_key,link) AS ( VALUES (1,17), (2,17), (3,17), (4,17), (6,17), (5,17) ),
> iter (id_key, row_type, link) AS (
>     SELECT 0, 'base', 17
>   UNION(
>     WITH remaining(id_key, row_type, link, min) AS (
>       SELECT tab.id_key, 'true'::text, iter.link, MIN(tab.id_key) OVER ()
>       FROM tab INNER JOIN iter USING (link)
>       WHERE tab.id_key > iter.id_key
>     ),
>     first_remaining AS (
>       SELECT id_key, row_type, link
>       FROM remaining
>       WHERE id_key=min
>     ),
>     effect AS (
>       SELECT tab.id_key, 'new'::text, tab.link
>       FROM first_remaining e INNER JOIN tab ON e.id_key=tab.id_key
>       /* Try changing this WHERE clause to other false expressions */
>       WHERE e.row_type='false'
>     )
>     SELECT * FROM first_remaining
>     /* Try uncommenting the next line */
>     --UNION SELECT * FROM effect
>   )
> )
> SELECT DISTINCT * FROM iter

Right offhand I'm inclined to think that the reference to "iter"
inside the first sub-WITH ought to be disallowed.  I don't recall
the exact rules about where a recursive reference can appear, but
it sure doesn't seem like that ought to be OK, does it?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Valentine Gogichashvili
Date:
Subject: Re: BUG #7494: WAL replay speed depends heavily on the shared_buffers size
Next
From: "Kevin Grittner"
Date:
Subject: Re: BUG #7495: chosen wrong index