On Thu, 27 Nov 2025 at 16:55, Tom Lane <[email protected]> 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
