Hi,
On June 13, 2019 3:38:47 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Andres Freund <andres@anarazel.de> writes:
>> I am too tired to look further into this. I suspect the only reason
>we
>> didn't previously run into trouble with the executor stashing
>hashkeys
>> manually at a different tree level with:
>> ((HashState *) innerPlanState(hjstate))->hashkeys
>> is that hashkeys itself isn't printed...
>
>TBH, I think 5f32b29c is just wrong and should be reverted for now.
>If there's a need to handle those expressions differently, it will
>require some cooperation from the planner not merely a two-line hack
>in executor startup. That commit didn't include any test case or
>other demonstration that it was solving a live problem, so I think
>we can leave it for v13 to address the issue.
I'm pretty sure you'd get an assertion failure if you reverted it (that's why it was added). So it's a bit more
complicatedthan that. Unfortunately I'll not get back to work until Monday, but I'll spend time on this then.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
