OK, I found a real solution: we can fix nodeWorktablescan.c so that the
order of initialization doesn't matter, by postponing the steps that
need information from the RecursiveUnion node until the first exec call
for the worktable node.
Although nodeCtescan is making a similar assumption about ini
> If we were to flatten it to a plain "select * from z" then maybe things
> would work all right, but the present implementation treats both WITH
> clauses as equally requiring single evaluation.
Surely it should be a single evaluation for each time that branch of
the upper WITH is recursively eva
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I'm inclined to prevent this case by forbidding recursive references
>> inside nested WITH clauses. Thoughts?
> I'm a bit puzzled where the root of the problem lies here. Surely the nested
> with clause is just eq
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> This crashes, apparently it tries to look up the result type on a NULL
>> planstate:
>> with recursive z(i) as (
>> select *
>> from t
>> union all
>> (with a(i) as (select * from z)
>>
Gregory Stark <[EMAIL PROTECTED]> writes:
> This crashes, apparently it tries to look up the result type on a NULL
> planstate:
> with recursive z(i) as (
> select *
> from t
> union all
> (with a(i) as (select * from z)
> select * from a)
> )
> select * from z;
Gregory Stark <[EMAIL PROTECTED]> writes:
> This crashes, apparently it tries to look up the result type on a NULL
> planstate:
Tsk tsk, running CVS HEAD without Asserts?
It looks like things are getting initialized in the wrong order. Maybe
we need to attach the initplan lower down.
> Incident
This crashes, apparently it tries to look up the result type on a NULL
planstate:
with recursive z(i) as (
select *
from t
union all
(with a(i) as (select * from z)
select * from a)
)
select * from z;
Incidentally, why are the parentheses required around the s
