You are right that tests I'd added in 0001 no longer test for the bugs it
fixes, that is, after applying your patch, because we no longer end up in
a state during *plan-time* pruning where those bugs manifest themselves.
Thanks for pointing that out. I have rewritten the tests.
Also, I'm attaching the other patch as *0002* this time to signal that it
is to be applied after applying yours, that is, if not together.
On 2019/05/15 11:47, David Rowley wrote:
> On Wed, 15 May 2019 at 14:20, David Rowley <david.rowley@2ndquadrant.com> wrote:
>> Additionally, I'm wondering if we should also apply the attached as
>> part of my dont_prune_with_nonimmutable_opfuncs_during_planning_v2.patch
>> patch. We should never get a non-Const in the pruning steps for
>> planning, so there's likely no point in doing a run-time check to
>> ensure we have a planstate. This code can execute quite often during
>> run-time pruning, once each time a parameter changes, which could be
>> each row. I think I'll go do that now, and also fix up that
>> forplanner comment you mentioned.
>
> I've made the change to partkey_datum_from_expr() in master's version
> only. I did this because I had to document that the context argument
> in get_matching_partitions() must have a valid planstate set when the
> given pruning_steps were generated for the executor. It's probably
> unlikely that anything else is using these functions, but still
> thought it was a bad idea to change that in v11. At this stage, I
> don't see any big issues changing that in master.
Agreed about changing that "if" to an "Assert" and doing it only in the
master. FWIW, I also ended up adding an Assert in the 0002 patch, because
one of the bugs being fixed can only occur in a run-time pruning scenario.
That means I had to create a version of the patch for v11 without the
Assert; that's the only difference between the attached pg11-0002- and
0002- patches.
Thanks,
Amit