Re: [HACKERS] WITH/RECURSIVE plans

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:

> On Fri, 2007-03-02 at 11:09 -0800, David Fetter wrote:
>> On Fri, Mar 02, 2007 at 10:52:14AM -0800, Joshua D. Drake wrote:
>> > Hello,
>> >
>> > Unfortunately we (the community) will not have WITH/RECURSIVE for 8.3.
>> > However I have spoken with a Alexey and Alvaro and Command Prompt has
>> > decided to make WITH/RECURSIVE a priority for 8.4.
>>
>> Any chance we can get WITH without RECURSIVE? That would be very
>> handy all by itself.
>
> I thought Greg already did submitted that?

I thought so too. Except then I tested it on more complex examples and it
didn't seem to work. Somehow the common table expression name wasn't being
propagated into the scope of subqueries. If that were fixed then, yes,
basically it's done.

I think in the long term we want common table expressions to not be executed
multiple times when they're referred to multiple times. So the existing
implementation which is basically just the syntax support and directly inlines
them wherever they're referenced, is inadequate. But there's nothing (aside
from the aforementioned failure to work) wrong with putting in something that
multiply evaluates now and avoiding the multiple evaluation later as an
optimisation.

Having said that I suppose one could argue it's incorrect to multiply evaluate
if there's a volatile function in the common table expression. But I could see
an equally strong argument for the converse. I'm wouldn't be too concerned
about that.

So...

The question I posed earlier was what types of data belong in the pstate and
what belongs in the parse node itself. I had the impression from the code that
the pstate was inherited when subqueries were planned (and restored after they
were done) so that made it the right place to keep the list of common table
expression names that were in scope.

Is that right? If so then I probably just have some mundane bug somewhere I
can track down now that I have some time. If not then what am I
misunderstanding about the pstate and where would be the right place to keep
this kind of parser namespace state?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com