Re: detoast datum into the given buffer as a optimization. - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: detoast datum into the given buffer as a optimization.
Date
Msg-id CAN-LCVM54qbeb1vwcgEY5=M66v2m5d0CT5sJd0MO2LK6CErPuA@mail.gmail.com
Whole thread Raw
In response to Re: detoast datum into the given buffer as a optimization.  (Andy Fan <zhihuifan1213@163.com>)
List pgsql-hackers
Hi!

Sorry for misguiding you, I've overlooked va_rawsize with va_extinfo.
You're right, va_rawsize holds uncompressed size, and extinfo actual
storage size. This was not intentional.

I'd better not count on caller's do know detoasted data length,
and much more the buffer is correctly initialized, because we cannot
check that inside and must rely on the caller, which would for sure
lead to unexpected segfaults, I agree with Tom Lane's proposal above.
Other options seem to be more crude and error-prone here. This is
an internal data fetching function and it should not generate new kinds
of errors, I think.

In case you're playing with this part of the code - I was always
confused with detoast_attr and detoast_external_attr functions
both marked as entry points of retrieving toasted data and both
look a lot the same. Have you ever thought of making a single
entry point by slightly redesigning this part?

--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Alias of VALUES RTE in explain plan
Next
From: Tom Lane
Date:
Subject: Re: Alias of VALUES RTE in explain plan