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:35 -0500 |
commit | bffe18e3e7dbb3c159361e62478c324ebe3041ec (patch) | |
tree | 815f08bb90a146911cd6b09d781b1fb8565f7b30 /src/tutorial/funcs.c | |
parent | a64e7e05a418ec26a76ecbf04c80e9ba7fe8aa90 (diff) | |
download | postgresql-bffe18e3e7dbb3c159361e62478c324ebe3041ec.tar.gz postgresql-bffe18e3e7dbb3c159361e62478c324ebe3041ec.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 'src/tutorial/funcs.c')
0 files changed, 0 insertions, 0 deletions