Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andy Fan <zhihuifan1213@163.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>, David Rowley <dgrowley@gmail.com>, Tomas Vondra <tomas@vondra.me>
Date: 2024-09-18T23:21:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid detoast in texteq/textne/byteaeq/byteane for unequal-length strings.

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