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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
