[ back to this patch... ]
Teodor Sigaev <teodor@sigaev.ru> writes:
>> Looked at this a bit ... do you think it's really a good idea to remove
>> the strategy number argument of comparePartial? The argument given in
>> the docs for it is that it might be needed to determine when to end the
>> scan, and that still seems plausible to me.
> Strategy number is not removed, it's replaced by pointer to opclass-specific
> data on per key basis. Actually, partial match feature is new for 8.4 and there
> is no any compatibility problem. None of existing opclasses (except
> contrib/btree_gin) uses strategy number in comparePartial.
I'm still not real happy about omitting the strategy number from
comparePartial's arguments. Yes, the extractQuery function can make
up for that if it has to, but why should it have to? It seems to me
to be inconsistent that the consistent function gets the strategy
number but comparePartial doesn't.
I know that there's not a backwards compatibility issue here, but it
still seems to me that you're forcing opclasses to do things the hard
way (allocating an extra_data entry) when they might only need
information that's already part of the call signature for existing
functions.
regards, tom lane