Re: Recursive query syntax ambiguity

"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