Hello David,
30.04.2024 03:48, David Rowley wrote:
> On Tue, 30 Apr 2024 at 02:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> One bit of research that needs to be done is whether btree will
>> truncate an "include"'d column of type name. I think it will not,
>> because that behavior is driven by the opclass and there isn't one
>> for an included column, but it wouldn't hurt to check. If so,
>> just restricting these setup loops to consider only indnkeyatts
>> columns should fix this.
> I did that research in the form of setting a breakpoint in
> index_deform_tuple() and verified the tup->t_info & 0xFFF grows by
> 64-bytes for each extra name column I INCLUDE. Also verified those
> extra bytes are all zero'd
Yes, I saw the same with pageinspect.
I could not find cases (I've tested also ranges and arrays based on the
name type) where the v4 behaves incorrectly, so I think it solves the
problem.
As a side note, perhaps this addition:
+#include "catalog/pg_opfamily_d.h"
is not needed for the current implementation.
Thank you for the fix!
Best regards,
Alexander
