Dean Rasheed <dean.a.rash...@gmail.com> writes: > On Wed, 23 Nov 2022 at 15:30, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Hmm ... this patch does not feel any more principled or future-proof >> than what it replaces, because now instead of making assumptions >> about what's in the jointree, you're making assumptions about what's >> in the targetlist.
> True, but it's consistent with what rewriteValuesRTE() does -- it has > to examine the targetlist to work out how items in the VALUES lists > are mapped to attributes of the target relation. That argument seems a little circular, because rewriteValuesRTE is taking it on faith that it's told the correct RTE to modify. >> I'm not 100% sure that product-query rewriting would always produce >> a FROM-list in this order, but I think it might be true. > No, the test case using rule r3 is a counter-example. In that case, > the product query has 2 VALUES RTEs, both of which appear in the > fromlist, and it's the second one that needs rewriting when it > recurses into the product query. Ah, right. I wonder if somehow we could just make one pass over all the VALUES RTEs, and process each one as needed? The problem is to identify the relevant target relation, I guess. regards, tom lane