"Tom Lane" <tgl@sss.pgh.pa.us> 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