"Tom Lane" <[EMAIL PROTECTED]> writes: > <search clause> ::= > SEARCH <recursive search order> SET <sequence column> > > and so CYCLE would come *after* "SET <sequence column>" not before it.
Ah, thanks, I had glossed right over the "SET <sequence column>" bit. The SET that I had was the "SET <cycle column>" which remains after the CYCLE keyword. > It looks to me like we'd have to promote SET to fully reserved status, > but that probably isn't going to surprise anyone. DEFAULT and USING > already are fully reserved. I don't see anything else here that looks > like it should need to be reserved. Having fixed that everything works fine with SET and WITH being reserved keywords. You didn't mean to say I should be able to leave WITH unreserved did you? Of course that was the easy part... Implementing non-recursive common table expressions should be fairly mechanical though I think I'll have lots of questions about how to get all the variable references fixed up. Non-recursive common table expressions are always non-correlated. They can refer to previous common table expressions but only to select from them either in the FROM clause or in subqueries. So as far as I can see they can just go in an InitPlan (or One-Time-Plan? I'm not sure what the distinction is) and be referred to in the same way. Recursive queries are of course a whole lot trickier. I've been slowly wrapping my head around them. So far I have a pretty good idea how to churn out a typical recursive query analogous to a CONNECT BY query. But the spec is a lot more ambitious than that. I haven't quite wrapped my head around the idea of mutually recursive or non-linearly-recursive queries yet. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
