Nikita Malakhov <huku...@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
