Re: detoast datum into the given buffer as a optimization.

Andy Fan <zhihuifan1213@163.com> writes:
>  *   Note if caller provides a non-NULL buffer, it is the duty of caller
>  * to make sure it has enough room for the detoasted format (Usually
>  * they can use toast_raw_datum_size to get the size)

This is a pretty awful, unsafe API design.  It puts it on the caller
to know how to get the detoasted length, and it implies double
decoding of the toast datum.

> One of the key point is we can always get the varlena rawsize cheaply
> without any real detoast activity in advance, thanks to the existing
> varlena design.

This is not an assumption I care to wire into the API design.

How about a variant like

struct varlena *
detoast_attr_cxt(struct varlena *attr, MemoryContext cxt)

which promises to allocate the result in the specified context?
That would cover most of the practical use-cases, I think.

            regards, tom lane