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