Re: Review: B-Tree emulation for GIN

The GIN_EXTRACT_VALUE macro returns a pointer to a static 'entries' 
variable. That doesn't seem safe. Is it really never possible to have to  two GIN searches in a plan, both calling and
usingthe value returned 
 
by extractValue simultaneously? In any case that seems like a pretty 
weak assumption.

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 
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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com