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.
The only change in
pg11_dont_prune_with_nonimmutable_opfuncs_during_planning_v3.patch
since v2 is the inaccurate comment mentioned by Amit.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services