On Sun, 10 Jun 2001, Tom Lane wrote:
> 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).
Oops. I forgot about that field.
> 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 ...
I guess the idea is to add a hash function to a catalog of a type
definition is a good idea?
> 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.
Thanks for pointer, I'll try to have a patch later :)