On 14.01.22 15:55, Denis Hirn 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:
[actually 7.17]
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.
Right, the above text does not impose any ordering of the UNION. It
just means that it has to have an operand that it not recursive. I
think that is what I was trying to say.
I don't understand what your RUNION examples are meant to show.
