Re: UPDATE: pg_dump fails due to invalid memory request

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