On 21.09.21 13:35, Denis Hirn wrote:
Also, currently a query like this works [...] but this doesn't:
WITH RECURSIVE t(n) AS (
SELECT n+1 FROM t WHERE n < 100
UNION ALL
VALUES (1)
)
SELECT sum(n) FROM t;
With your patch, the second should also work, so let's show some tests for that
as well.
With just the tree rotation, the second query can not be fixed. The order of two
nodes is never changed. And I think that this is a good thing. Consider the
following query:
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
SELECT n+1 FROM t WHERE n < 100
UNION ALL
VALUES (2)
) SELECT * FROM t LIMIT 100;
If we'd just collect all non-recursive UNION branches, the semantics of the
second query would change. But changing the semantics of a query (or preventing
certain queries to be formulated at all) is not something I think this patch
should do. Therfore – I think – it's appropriate that the second query fails.
I have been studying this a bit more. I don't understand your argument
here. Why would this query have different semantics than, say
WITH RECURSIVE t(n) AS (
VALUES (1)
UNION ALL
VALUES (2)
UNION ALL
SELECT n+1 FROM t WHERE n < 100
) SELECT * FROM t LIMIT 100;
The order of UNION branches shouldn't be semantically relevant.
I suppose you put the LIMIT clause in there to make some point, but I
didn't get it. ;-)
I also considered this example:
WITH RECURSIVE t(n) AS (
(VALUES (1) UNION ALL VALUES (2))
UNION ALL
SELECT n+1 FROM t WHERE n < 100
)
SELECT sum(n) FROM t;
This works fine without and with your patch.
This should be equivalent:
WITH RECURSIVE t(n) AS (
VALUES (1) UNION ALL (VALUES (2)
UNION ALL
SELECT n+1 FROM t WHERE n < 100)
)
SELECT sum(n) FROM t;
But this runs forever in current PostgreSQL 14 and 15. I'd have
expected your patch to convert this form to the previous form, but it
doesn't.
I'm having difficulties understanding which subset of cases your patch
wants to address.
