Re: [PATCH] Allow multiple recursive self-references

> On 14. Jan 2022, at 13:21, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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