On Sun, 3 Mar 2019 at 17:11, Tom Lane <tgl@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.rowley@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