On Sun, 3 Mar 2019 at 17:11, Tom Lane <t...@sss.pgh.pa.us> wrote: > (At the code level, this is implicit in the fact that the comparison > function will be called via FunctionCall2Coll or a sibling, and those > all throw an error if the called function returns NULL.) > > Now, it doesn't say in so many words that the comparison operators > have to yield results consistent with the comparison support function, > but I think that's pretty obvious ...
Ah okay. I can get it to misbehave by setting fcinfo->isnull = true in the debugger from int4eq(). I see the NULL result there is not verified as that's just translated into "false" by ExecInterpExpr()'s EEOP_QUAL case. If you're saying something doing that is fundamentally broken, then I guess we're okay. > David Rowley <david.row...@2ndquadrant.com> writes: > > The list of builtin types that have a hash opfamily but no btree > > opfamily that support NOT IN are not very exciting, so doing the same > > for hash might not be worth the extra code. > > Agreed for builtin types, but there might be some extensions out there > where this doesn't hold. It's not terribly hard to imagine a data type > that hasn't got a linear sort order but is amenable to hashing. On reflection, it seems pretty easy to add this check, so I've done so in the attached. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
not_in_anti_join_v1.3.patch
Description: Binary data
