JanWieck@t-online.de (Jan Wieck) writes:
> 3. Tom, we don't have a consensus how to merge the TOAST
> related function changes with the fmgr changes up to now.
> Which base type specific functions will be touched due to
> fmgr changes right now?
For functions that need their inputs de-toasted, I think that the
changes you need should be a free byproduct of the fmgr changes.
I'd recommend we make those changes first, and then in a cleanup pass
you can modify anything that is able to work on still-toasted input.
I can't really do much with updating any varlena datatypes until
there's a version of heap_tuple_untoast_attr() somewhere in the
system --- if you look at src/include/fmgr.h, you'll see the call
is already there:
/* use this if you want the raw, possibly-toasted input datum: */
#define PG_GETARG_RAW_VARLENA_P(n) ((struct varlena *) PG_GETARG_POINTER(n))
/* use this if you want the input datum de-toasted: */
#define PG_GETARG_VARLENA_P(n) \(VARATT_IS_EXTENDED(PG_GETARG_RAW_VARLENA_P(n)) ? \ (struct varlena *)
heap_tuple_untoast_attr((varattrib*) PG_GETARG_RAW_VARLENA_P(n)) : \ PG_GETARG_RAW_VARLENA_P(n))
/* GETARG macros for varlena types will typically look like this: */
#define PG_GETARG_TEXT_P(n) ((text *) PG_GETARG_VARLENA_P(n))
BTW, it would save some casting if heap_tuple_untoast_attr were declared
to accept and return "struct varlena *" ...
Anyway, as soon as that code links to something that works, let me know
and I'll make a pass over the "text" functions. That should give you
something to test with.
regards, tom lane
