diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2019-11-19 17:03:26 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2019-11-19 17:03:34 -0500 |
commit | b3c265d7be42484bd0ab4a9c0a920289e8f5c995 (patch) | |
tree | cddd227be605fc0cdbbf47e86561e0580c4077ab /contrib/btree_gist/btree_inet.c | |
parent | b107140804817cc30a4069b1bb5545aa3ea0ce6c (diff) | |
download | postgresql-b3c265d7be42484bd0ab4a9c0a920289e8f5c995.tar.gz postgresql-b3c265d7be42484bd0ab4a9c0a920289e8f5c995.zip |
Fix corner-case failure in match_pattern_prefix().
The planner's optimization code for LIKE and regex operators could
error out with a complaint like "no = operator for opfamily NNN"
if someone created a binary-compatible index (for example, a
bpchar_ops index on a text column) on the LIKE's left argument.
This is a consequence of careless refactoring in commit 74dfe58a5.
The old code in match_special_index_operator only accepted specific
combinations of the pattern operator and the index opclass, thereby
indirectly guaranteeing that the opclass would have a comparison
operator with the same LHS input type as the pattern operator.
While moving the logic out to a planner support function, I simplified
that test in a way that no longer guarantees that. Really though we'd
like an altogether weaker dependency on the opclass, so rather than
put back exactly the old code, just allow lookup failure. I have in
mind now to rewrite this logic completely, but this is the minimum
change needed to fix the bug in v12.
Per report from Manuel Rigger. Back-patch to v12 where the mistake
came in.
Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com
Diffstat (limited to 'contrib/btree_gist/btree_inet.c')
0 files changed, 0 insertions, 0 deletions