Laurenz Albe <laurenz.a...@cybertec.at> writes:
> On Tue, 2023-01-10 at 15:53 +0000, PG Doc comments form wrote:
>>> PLAIN prevents either compression or out-of-line storage; furthermore it
>>> disables use of single-byte headers for varlena types. This is the only
>>> possible strategy for columns of non-TOAST-able data types.
>> However, it does allow "single byte" headers. How to verify this?
>> CREATE EXTENSION pageinspect;
>> CREATE TABLE test(a VARCHAR(10000) STORAGE PLAIN);
>> INSERT INTO test VALUES (repeat('A',10));
>>
>> Now peek into the page with pageinspect functions
>>
>> SELECT left(encode(t_data, 'hex'), 40) FROM
>> heap_page_items(get_raw_page('test', 0));
>>
>> This returned value of "1741414141414141414141".
> I think that the documentation is wrong. The attached patch removes the
> offending half-sentence.
The documentation is correct, what is broken is the code. I'm not
sure when we broke it, but what I see in tracing through the INSERT
is that we are forming the tuple using a tupdesc with the wrong
value of attstorage. It looks like the tupdesc belongs to the
virtual slot representing the output of the INSERT statement,
which is not identical to the target relation's tupdesc.
(The virtual slot's tupdesc is probably reverse-engineered from
just the data types of the columns, so it'll have whatever is the
default attstorage for the data type. It's blind luck that this
attstorage value isn't used for anything more consequential,
like TOAST decisions.)
regards, tom lane
