> On 14. Jan 2022, at 13:21, Peter Eisentraut > <peter.eisentr...@enterprisedb.com> wrote:
> > There is nothing in there that says that certain branches of the UNION in a > recursive query mean certain things. In fact, it doesn't even require the > query to contain a UNION at all. It just says to iterate on evaluating the > query until a fixed point is reached. I think this supports my claim that > the associativity and commutativity of a UNION in a recursive query still > apply. > > This is all very complicated, so I don't claim this to be authoritative, but > I just don't see anything in the spec that supports what you are saying. I disagree. In SQL:2016, it's discussed in 7.16 <query expression> syntax rule 3) j) i), which defines: > 3) Among the WQEi, ... WQEk of a given stratum, there shall be at least one > <query expres- > sion>, say WQEj, such that: > A) WQEj is a <query expression body> that immediately contains UNION. > B) WQEj has one operand that does not contain a <query name> referencing > any of WQNi, > ..., WQNk. This operand is said to be the non-recursive operand of > WQEj. > C) WQEj is said to be an anchor expression, and WQNj an anchor name. Where <query expression body> is defined as: > <query expression body> ::= > <query term> > | <query expression body> UNION [ALL | DISTINCT] > [ <corresponding spec> ] <query term> > > <query term> ::= > <query primary> > | ... > > <query primary> ::= ... > | <left paren> <query expression body> ... <right paren> This definition pretty much sums up what I have called RUNION. The SQL standard might not impose a strict order on the UNION branches. But you have to be able to uniquely identify the anchor expression. Best, -- Denis
