From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David E. Wheeler" <david@justatheory.com>
cc: Noah Misch <noah@leadboat.com>,
        Aleksander Alekseev <aleksander@timescale.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        Marco Slot <marco.slot@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Christoph Berg <myon@debian.org>,
        Pavan Deolasee <pavan.deolasee@gmail.com>
Subject: Re: Potential ABI breakage in upcoming minor releases
In-reply-to: <900DE0C9-48C4-474C-BDC9-AD495D8D3F59@justatheory.com>
References: <1976928.1731614974@sss.pgh.pa.us> <202411142033.u6za5a6ylj2k@alvherre.pgsql> <20241114224108.d0.nmisch@google.com> <CAJ7c6TPcUJq_Bwo69f6ysRA1UbmSh_hOOEzJ2EvM0cW=3VEh5w@mail.gmail.com> <CAFMSG9Hy-2-8tfmmKy7noCbA3Yn1UY2SFUwYj7wHODTO8gDm8w@mail.gmail.com> <CAJ7c6TMCc85YoiSKex5Sztz6bEmV-0YqL7FY=_MxxcyoMGTDfQ@mail.gmail.com> <2443809.1731683394@sss.pgh.pa.us> <20241115175223.68.nmisch@google.com> <2483970.1731702561@sss.pgh.pa.us> <2500050.1731705196@sss.pgh.pa.us> <900DE0C9-48C4-474C-BDC9-AD495D8D3F59@justatheory.com>
Comments: In-reply-to "David E. Wheeler" <david@justatheory.com>
	message dated "Fri, 15 Nov 2024 19:00:02 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2638275.1731717056.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 15 Nov 2024 19:30:56 -0500
Message-ID: <2638276.1731717056@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2638276.1731717056%40sss.pgh.pa.us>
Precedence: bulk

"David E. Wheeler" <david@justatheory.com> writes:
> On Nov 15, 2024, at 16:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In other words, our current guidelines
>> for preserving ABI compatibility actually *created* this disaster,
>> because the HEAD change was fine from an ABI standpoint but what
>> was done in back branches was not.  So we do need to rethink how
>> that's worded.

> What bit is mis-worded? The guidance Peter committed[1] says that =E2=80=
=9CPostgreSQL makes an effort to avoid server
> ABI breaks in minor releases.=E2=80=9D

That text says exactly nothing about what specific code changes to
make or not make.  I'm not sure offhand where (or if) we have this
documented, but there's an idea that adding fields at the end of
a struct is safer ABI-wise than putting them in the middle.  Which
is true if you can't squeeze them into padding space.  Here, that
could have been done and probably should have.

The other bit of documentation we probably need is some annotation in
struct ResultRelInfo saying "do not change the sizeof() this struct
in back branches, period".

			regards, tom lane