Re: Another multi-row VALUES bug

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Wed, 23 Nov 2022 at 15:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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