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

Nikita Malakhov <hukutoc@gmail.com> writes:

> 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.

That's OK, so we are in the same page here.

> 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.

Tom'sreply depends on the fact I was going to changing the "detoast_attr"
to "detoast_attr_buffer", as I have expalined in my previous post. I
don't think a [new] user provided buffer function is so harmful. What
do you think about function "text_to_string_buffer"?  This is also a
part in my previous reply, but is ignored by your reply? 

> 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?

You can check [1] for a indepent improvements for this topic.

[1] https://www.postgresql.org/message-id/874j4vcspl.fsf%40163.com 

-- 
Best Regards
Andy Fan