On Sat, Sep 03, 2005 at 02:40:59PM -0700, Morgan Kita wrote:
> I was using the MACRO PG_GETARG_POINTER(0). From reading the manual on
> this page: http://www.postgresql.org/docs/8.0/interactive/xtypes.html
> and combining it with the example above, I made the wrong assumption
> that it was calling pg_detoast_datum underneath. I now used the
> preprocessor to figure out that it just returns a raw pointer.
The Complex type in that page's example has internallength = 16;
it's not a varlena type so it doesn't have to be detoasted.
Note the comments in the penultimate paragraph on that page regarding
variable-length types:
The C functions operating on the data type must be careful to
unpack any toasted values they are handed, by using PG_DETOAST_DATUM.
(This detail is customarily hidden by defining type-specific GETARG
macros.)
> So I am switching to the macro PG_GETARG_VARLENA_P(0)... does that seem
> correct? The macro expansion appears to be correct, but I would just
> apperciate some verification.
That macro is defined in fmgr.h as
#define PG_GETARG_VARLENA_P(n) PG_DETOAST_DATUM(PG_GETARG_DATUM(n))
so I think it should work. For my own varlena types I've been doing
something like the following to mimic the macros for the standard
types (see fmgr.h):
#define DatumGetMytypeP(X) ((mytype *)PG_DETOAST_DATUM(X))
#define PG_GETARG_MYTYPE_P(n) DatumGetMytypeP(PG_GETARG_DATUM(n))
With these macros, code can simply use PG_GETARG_MYTYPE_P(n) without
worrying about the detail of detoasting.
--
Michael Fuhr