Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> This isn't going to be a particularly simple fix :-(. The basic
>> implementation clearly ought to be to dump the result of the subquery
>> into a tuplestore and then have the upper level read out from that.
>> However, we don't have any infrastructure for having multiple
>> upper-level RTEs reference the same tuplestore.
> Uhm, indeed, isn't that the whole point of the work needed to make recursive
> queries work?
No, I don't think so. The present patch (so far as I've gathered what
it can do, in the absence of any documentation) knows how to feed back
tuples collected at an upper level to a scan node at a lower level,
which is needed to implement recursion. However, if you do
WITH RECURSIVE foo AS (...) SELECT ... FROM foo a, foo b WHERE
then you will still get two independent evaluations of duplicate
querytrees. Which is at least a performance bug, and if there are
any volatile functions inside foo I claim it's a spec violation too.
regards, tom lane