]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix partition pruning to treat stable comparison operators properly.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 16 May 2019 15:58:22 +0000 (11:58 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 16 May 2019 15:58:22 +0000 (11:58 -0400)
commit10c5cc4b4f88d249751e27034a8dd59ea903a698
treea4b226f3d90a622e1d2e326de9769502d97a0618
parent05cf41973157577aac9706dcc7998054949b0ed4
Fix partition pruning to treat stable comparison operators properly.

Cross-type comparison operators in a btree or hash opclass might be
only stable not immutable (this is true of timestamp vs. timestamptz
for example).  partprune.c ignored this possibility and would perform
plan-time pruning with them anyway, possibly leading to wrong answers
if the environment changed between planning and execution.

To fix, teach gen_partprune_steps() to do things differently when
creating plan-time pruning steps vs. run-time pruning steps.
analyze_partkey_exprs() also needs an extra check, which is rather
annoying but now is not the time to restructure things enough to
avoid that.

While at it, simplify the logic for the plan-time case a little
by insisting that the comparison value be a Const and nothing else.
This relies on the assumption that eval_const_expressions will have
reduced any immutable expression to a Const; which is not quite
100% true, but certainly any case that comes up often enough to be
interesting should have simplification logic there.

Also improve a bunch of inadequate/obsolete/wrong comments.

Per discussion of a report from Alan Jackson (though this fixes only one
aspect of that problem).  Back-patch to v11 where this code came in.

David Rowley, with some further hacking by me

Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com
src/backend/partitioning/partprune.c
src/test/regress/expected/partition_prune.out
src/test/regress/sql/partition_prune.sql