> 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.
> The description of extractQuery's extra_data parameter seems confusing
> too. AFAICS it is incorrect, or at least misleading, to describe it as
> void ** extra_data[]; it is really void ***extra_data, because there is
> only one object there not an array.
It's really array, see fillScanKey() in ginscan.c, line 61 of patched file.
extractQuery could provide data for each returned key.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
