Re: remove ATTRIBUTE_FIXED_PART_SIZE

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: remove ATTRIBUTE_FIXED_PART_SIZE
Date: 2018-08-18 20:41:32
Message-ID: D242153C-0865-47AD-AC76-FB148E0B84C7@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On August 18, 2018 8:37:00 PM GMT+02:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> Since the introduction of the CATALOG_VARLEN stuff, the fixed size of
>> pg_attribute is exactly sizeof(FormData_pg_attribute), so the ancient
>> mechanism to track the fixed size manually using
>> ATTRIBUTE_FIXED_PART_SIZE can be removed.
>
>Meh, I'm not sure about this. What about the possibility of trailing
>padding after the last fixed column, as the comment you propose to
>remove is talking about? Sure, we don't have that today, but we
>might again the next time somebody adds a column to pg_attribute.

Where would avoiding that padding be an important thing her? Strictly speaking it's not even safe to access the last members without the padding present - the compiler is free to store with a wider write if that just affects padding. GCC does that in some cases IIRC.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-08-18 21:05:02 Re: remove ATTRIBUTE_FIXED_PART_SIZE
Previous Message Tom Lane 2018-08-18 20:34:50 Re: Allowing printf("%m") only where it actually works