Re: gist access methods parameter types

Marios Vodas <mvodas(at)gmail(dot)com> writes:
> I am implementing consistent, union, compress, decompress, penalty,
> picksplit and same.
[…]
> The problem is that some of these methods take as input parameters
> the d_type and some the struct type that I internally implemented in
> c (which will be saved to the tree).

That shouldn't be a problem as you're going to implement the functions
in C too, I guess. After all an index is all about performances.

http://www.postgresql.org/docs/current/static/gist-implementation.html
http://wiki.postgresql.org/wiki/Image:Prato_2008_prefix.pdf

Please not that the documentation here has been true in 8.3 too but
didn't get backpatched there. Maybe we should consider?

> If I understand correctly consistent and compress are the only
> functions that will have input parameter of d_type. The others will
> have my c internal type.
> Is this correct?

Well how is your C coded type different from d_type and why?

> Something else, will a non-leaf node have one entry that will be
> produced by union? I am asking because I want the leaf node entries
> to be of different type from non-leaf node entries (the difference
> between them is that non-leaf entry will not keep the id attribute).

Non-leaf nodes will contain a page full of entries all consistent with
each-other and sharing a common union. You can have leaf nodes entries
of a different type with the STORAGE option of the CREATE OPERATOR CLASS
command here, and the compress() and decompress() methods:

http://www.postgresql.org/docs/current/static/sql-createopclass.html

Then you have to take care about that in several of the functions in the
GiST API, in particular in consistent, see the GIST_LEAF(entry) macro.

Your main source of documentation at this point lies in the source of
the different GiST implementations, see ip4r, period, prefix and some
more.

Regards,
--
dim