Re: gist access methods parameter types

On Mon, Sep 27, 2010 at 10:37 AM, Marios Vodas <mvodas(at)gmail(dot)com> wrote:
> Let me explain better what I want to do.
> I want to have the types in sql level (composite types) like this:
>
> --Spatio-Temporal Position in 3 Dimensions(cartessian x, cartessian y, time)

Have you looked at PostGIS?

> As you see the first is a replica of my sql type in C and the second misses
> some information (it is just the minimum bounding box which means that we
> don't know initial/ending positions neither the trajectory id). The second
> type is intended for non-leaf nodes while the first for leaf nodes.

Yeah, I still don't think that's the right way to do it. Storing the
bounding box seems right, but just do that for all the nodes. It's
probably worth looking at the implementation of these functions for,
say, the existing point, box, and polygon datatypes, which have
similar issues.

> My implementation of the tree is a kind of 3D-Rtree.
> Now I am a little confused about the type of the arguments that each access
> method (consistent, union, compress, decompress, penalty, picksplit, same)
> requires in order to accomplish my goal.
> Another black spot I have regarding compress.
> If the entry passed to compress is a leaf entry then it is going to be of
> sql type (composite type) delta3d (meaning I will get the values using
> tuples etc). Correct? If not of what type is it going to be?

According to the documentation, no. It takes a GISTENTRY and returns
a GISTENTRY. But you can extract the relevant key out of there. The
best way to do this, again, is to look at existing examples, like
gist_poly_compress.

> Assume it is a non-leaf entry. In that case of what type will it be? If it
> is delta3d_mbb (C type) then I don't have to change it. But is it going to
> be?
> I am sorry if I seem importunate, but it has only been 2 weeks since I
> started messing with postgresql C extensions, and I need help...

If you need a moderate amount of help, you can probably get it the way
that you have been: asking questions. If you need more help than
that, see http://www.postgresql.org/support/professional_support

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company