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.
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 |