In GiST, for each new data type we support we're expected to provide
(among other things) a function to determine whether a query is
consistent with a particular index entry (given an operator/
strategy). I haven't been able to figure out when the query value
being passed (arg 1 in the <datatype>_consistent function) is the
actual value (say the value "6"), or a pointer to the value. In the
btree_gist contrib examples, I see both cases (int4, a value; text, a
pointer). Does anyone know how to tell when when the gist consistent
function should expect a pointer or a value (apparently this is setup
in the scankey in a generic fashion before getting into the index-
specific implementation but can't tell how exactly)? Does this depend
on the storage clause in CREATE TYPE?
Also, a broader question. GiST is setup to evaluate each column in
the index in the order it was specified (e.g. if the index has colX,
colY, then if colX satisfies the search, colX is checked, otherwise
colY is ignored)...as in traditional btree indexes. I would like to
set up a multi-dimensional index that doesn't require all data to be
contained in a single column (like an rtree index where the X and Y
coordinates would be in different columns rather than a single
composite column). I have taken the approach of hacking some of the
GiST code to do this (basically, my code looks at each itup on a page
and evaluates on multiple columns at once, depending on strategy and
according to my algorithm). This bypasses some of the existing GiST
code but takes advantage of a lot of it (recovery features, etc.), but
it's a reluctant and probably temporary hack. So my question....is
this type of initiative already in the works in some project out
there? Hate to duplicate effort. GiST takes you a long way but not
quite all the way for these types of scenarios.
Thanks
Eric