Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Tom Lane wrote: > >> Bottom line is that somebody failed to consider the possibility of a > >> null comparison value reaching the BRIN index lookup machinery. > >> The code stanza that's failing supposes that only IS NULL or IS NOT NULL > >> tests could have SK_ISNULL set, but that's just wrong. > > > I think the easiest way to solve this is to consider that all indexable > > operators are strict, and have the function return false in that case. > > The attached patch implements that. > > This looks fine to me as a localized fix. I was wondering whether we > could short-circuit the index lookup further upstream, but I take it from > your comment about _bt_preprocess_keys that BRIN has no convenient place > for that today. (Even if it did, I'd still vote for making this change, > for safety's sake.)
Yeah, it doesn't currently. Hopefully we will improve that in the future. Particularly with regards to array keys I think there's a lot to be done there. I pushed this as is. I hesitated about adding a regression test, but it didn't seem worthwhile in the end, because if in the future we improve scan key analysis, we will need much more extensive testing, and this doesn't look like the type of bug that we could reintroduce in a whim. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
