"Simon Riggs" <simon@xxxxxxxxxxxxxxx> 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
