Re: Cross-type index comparison support in contrib/btree_gin

Arseniy Mukhin <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com> writes:
> Sorry, I think I wasn't clear enough. I agree with this logic, but I
> think it implies an impossible scenario for the "equals" case. The
> scenario where during a scan we first have keys that are less than
> orig_datum, and then a key that is equal to orig_datum. Why I think
> such a scenario is impossible: GIN uses partial_key as a lower bound
> when positioning the start of a partial match scan. So if there is any
> key in the index that is equal to "partial key", it must be the very
> first key in the scan. Then if the very first key in the scan is less
> than orig_datum, that means partial_key was also less than orig_datum
> (because partial_key is a lower bound). And the only reason
> partial_key might not be equal to orig_datum is that there is no value
> equal to orig_datum in the index type. So we can say that if the very
> first key in the scan is less than orig_datum, then there is no key in
> the index that could be equal to orig_datum, and we can stop right
> there.

OK, I got your point finally. It seems perhaps a little fragile
to write the code like this, but I agree that it should work.

v5 attached incorporates your test additions and responds to your
other review suggestions. Also, I changed the representation of
the opclass strategy numbers to use 4 bits for the btree strategy,
because I realized that we could write the strategy numbers in the
.sql file as hex literals and thereby improve readability --- the
RHS type and the btree strategy are now independent hex digits
in the DDL.

regards, tom lane