> > Everything is always passed as a Datum, so yes, it's is determined by > the storage clause in CREATE TYPE.
Still not sure what to do in some scenarios. One example is the gist example code for btree (btree_gist). If you look at the int4 example consistent function, it gets an int32 value (param 1). For other data types, it would get a pointer to a value. Is the rule anything <= 4 bytes it's a value, above that it's a pointer? See the code below... Datum gbt_int4_consistent(PG_FUNCTION_ARGS) { GISTENTRY *entry = (GISTENTRY *) PG_GETARG_POINTER(0); int32 query = PG_GETARG_INT32(1); int32KEY *kkk = (int32KEY *) DatumGetPointer(entry->key); > > The usual approach to this is to define the index on a composite of > the values. For example, if you have a table with two points that you > want to index together, you do: > > CREATE INDEX foo ON bar((box(point1,point2))); > > i.e. a functional index on the result of combining the points. It does > mean you need to use the same syntax when doing the queries, but it > works with modifying any internal code at all... > > Given you can use rowtypes more easily these days, it's quite possible > you use build an operator class on a row type... > > Have a nice day, > -- > Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > > > From each according to his ability. To each according to his ability to > > litigate. > > Thanks Martijn. I will consider that approach. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match