On Thu, 27 Nov 2025 at 16:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Hmmm ... I don't love this particular implementation, because it
> is doubling down on the already-undesirable assumption that the
> rule CTEs have no name conflicts with the outer query's CTEs.
> Still, unless somebody sets out to remove that restriction,
> it won't matter. (It'd be a good idea for the comments here
> to point that out though.)
>
> I do think there's another way we could attack it. Similarly
> to the way VALUES RTEs are either processed or skipped by
> checking the rangetable length, we could pass down the length
> of the outer query's cteList, and assume that the last N entries
> in a product query's cteList have already been processed.
> (Last N not first N because of the order in which the lists are
> concatenated at line 596.) Maybe that's too fragile, but the
> approach seems to have worked all right for VALUES.
>
Yes, that was my original thinking, but I wasn't keen to add more code
that depended on the order in which some other function added things
to a list. It kind-of had to be that way for VALUES RTEs because they
don't have any other identifiers, but I thought that since CTEs do, it
might as well use them.
On the other hand, passing a single integer ought to be simpler than
passing a list round and iterating through it, so perhaps that way is
worth investigating.
Regards,
Dean
