Teodor Sigaev wrote:
>> You might want to declare extra_data as just "void *", instead of an
>> array of pointers. The data type implementation might want to store
>> something there that's not per-key, but applies to the whole query. I
>> see that you're passing it to comparePartial, but that seems to be
>> just future-proofing. What kind of a data type are you envisioning
>> that would
>
> wildspeed module (http://www.sigaev.ru/cvsweb/cvsweb.cgi/wildspeed/) -
> for each key from it's needed to store some info. Right now it's coded
> directly in Datum, but it looks ugly (at least for me).
Ok, I guess it's best to leave it as you had in the patch then.
>> make use of it? It seems that you could pass the same information in
>> the partial key Datum itself that extractQuery returns. You're
>> currently using it as a way to avoid some palloc's in
>> gin_tsquery_consistent(). That seems like a pretty dirty hack. I doubt
>> there's any meaningful performance advantage from that, but if there
>> is, I think you could use a statically allocated array instead.
>
> It's easy to un-dirty that hack, but before I'd like to see your
> comments about thoughts above.
Yeah, please revert that hack.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com