Re: Remove restrictions in recursive query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Renan Alves Fonseca <renanfonseca(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remove restrictions in recursive query
Date: 2025-03-28 00:14:16
Message-ID: 2215554.1743120856@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Renan Alves Fonseca <renanfonseca(at)gmail(dot)com> writes:
> I suspected that this restriction came straight from the specs. I
> understand that while the proposed solution can help in some specific
> use cases, it is not enough to justify an exception to the spec.

Well, we extend the spec in lots of places. I'd be okay with removing
this restriction if I were sure there were no bad consequences, but
it seems likely that there are some. College math was way too long
ago for me to be sure about the "fixed-point" business ... but I think
what they may be on about is that rows produced by aggregation may not
be stable in the face of adding more and more rows via additions to
the recursion workspace. In your example, I think it somewhat
accidentally doesn't matter: an underlying row might get picked up
and added to a dag.target-grouped row in one recursion step or
a different one, but then you sum all those sums in the top-level
query, so the top sum comes out the same regardless of just what sets
the intermediate grouped rows consisted of. With a different query
construction though, that would matter.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-03-28 00:33:09 RE: Selectively invalidate caches in pgoutput module
Previous Message Chapman Flack 2025-03-28 00:12:47 Bringing non-atomic operation to a PL that hasn't had it