diff options
| author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2015-07-30 15:07:19 -0300 |
|---|---|---|
| committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2015-07-30 15:07:19 -0300 |
| commit | c81276241b61d8759e024ed803e8f3f251d8e7c9 (patch) | |
| tree | 3b909a6f7de7416644257c39433f41011b9390ce /src/backend/utils/adt/regexp.c | |
| parent | d6314b20cd872a542d71738df54a906d2962abb8 (diff) | |
| download | postgresql-c81276241b61d8759e024ed803e8f3f251d8e7c9.tar.gz postgresql-c81276241b61d8759e024ed803e8f3f251d8e7c9.zip | |
Fix broken assertion in BRIN code
The code was assuming that any NULL value in scan keys was due to IS
NULL or IS NOT NULL, but it turns out to be possible to get them with
other operators too, if they are used in contrived-enough ways. Easiest
way out of the problem seems to check explicitely for the IS NOT NULL
flag, instead of assuming it must be set if the IS NULL flag is not set,
when a null scan key is found; if neither flag is set, follow the lead
of other index AMs and assume that all indexable operators must be
strict, and thus the query is never satisfiable.
Also, add a comment to try and lure some future hacker into improving
analysis of scan keys in brin.
Per report from Andreas Seltenreich; diagnosis by Tom Lane.
Backpatch to 9.5.
Discussion: http://www.postgresql.org/message-id/20646.1437919632@sss.pgh.pa.us
Diffstat (limited to 'src/backend/utils/adt/regexp.c')
0 files changed, 0 insertions, 0 deletions