From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, suchithjn22(at)gmail(dot)com, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: The documentation for storage type 'plain' actually allows single byte header |
Date: | 2023-01-15 23:03:20 |
Message-ID: | 20230115230320.d3mtlzek6dv7mgxx@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
Hi,
On 2023-01-15 16:40:27 -0500, Tom Lane wrote:
> The documentation is correct, what is broken is the code. I'm not
> sure when we broke it
Looks to be an old issue, predating the slot type stuff. It reproduces at
least as far back as 10.
I've not thought through this fully. But after a first look, this might be
hard to fix without incuring a lot of overhead / complexity. We check whether
projection is needed between nodes with tlist_matches_tupdesc() - targetlists
don't know about storage. And we decide whether we need to project in
nodeModifyTuple solely based on
/* Extract non-junk columns of the subplan's result tlist. */
foreach(l, subplan->targetlist)
{
TargetEntry *tle = (TargetEntry *) lfirst(l);
if (!tle->resjunk)
insertTargetList = lappend(insertTargetList, tle);
else
need_projection = true;
}
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-15 23:08:21 | Re: The documentation for storage type 'plain' actually allows single byte header |
Previous Message | Tom Lane | 2023-01-15 21:40:27 | Re: The documentation for storage type 'plain' actually allows single byte header |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-15 23:08:21 | Re: The documentation for storage type 'plain' actually allows single byte header |
Previous Message | Tom Lane | 2023-01-15 23:02:07 | Re: Extracting cross-version-upgrade knowledge from buildfarm client |