Re: inet type/merge joins

Alex Pilosov <alex@pilosoft.com> writes:
> a) inet and cidr should be hashable

That's not safe.  The critical requirement for hashability (in its
present implementation) is that two values with distinct bit patterns
must never compare as equal.  This is not true for inet/cidr, since
the comparison function doesn't pay attention to the 'type' field
(inet vs. cidr).

At some point it'd be nice to use type-specific hash functions for
hashjoin --- we support 'em for hash indexes, and I don't see why the
join mechanism should not use the same functions.  With that, it'd be
possible to overcome this problem by making a hash function that has
the same blind spots as the comparison function ...

But you're right that the network types should be mergejoinable;
anything that supports btree indexes ought to be mergejoinable.
I see a couple of similar omissions now that I look.  Will fix.

> I'm also thinking that <<, <<=, etc functions must be using an index, but
> I'm still trying to understand the way pg_operator, pg_amop, pg_amproc all
> fit together...

I think you'd be better off to hack these into the "special index
operator" stuff in optimizer/path/indxpath.c.  Adding to pg_amop
would only be appropriate for something that you could define in a
datatype-independent fashion.
        regards, tom lane