Re: inconsistent results querying table partitioned by date

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(dot)rowley(at)2ndquadrant(dot)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