MIME-Version: 1.0
References: <ZtpgHSGPrQNTZ-mX@momjian.us> <202409070955.wyuhquqflbxg@alvherre.pgsql>
 <Zt-zGmTub6eK_Z7W@momjian.us> <CAGECzQQfRVehQON65qNu-T_1O7VE+aFi0uPgvSEG4PHaijbUiw@mail.gmail.com>
 <ZuGk0krk-TIgP-dD@momjian.us>
In-Reply-To: <ZuGk0krk-TIgP-dD@momjian.us>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Tue, 17 Sep 2024 10:01:28 +0200
Message-ID: <CAGECzQQ-ec-=HKRaD3y7b_Z5Vo4HxztAknG04RVG3HLwJvsguw@mail.gmail.com>
Subject: Re: First draft of PG 17 release notes
To: Bruce Momjian <bruce@momjian.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Nathan Bossart <nathandbossart@gmail.com>, 
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAGECzQQ-ec-%3DHKRaD3y7b_Z5Vo4HxztAknG04RVG3HLwJvsguw%40mail.gmail.com>
Precedence: bulk

On Wed, 11 Sept 2024 at 16:10, Bruce Momjian <bruce@momjian.us> wrote:
> You are right that I do mention changes specifically designed for the
> use of extensions, but there is no mention in the commit message of its
> use for extensions.  In fact, I thought this was too low-level to be of
> use for extensions.  However, if people feel it should be added, we have
> enough time to add it.

Another new API that is useful for extension authors is the following
one (I'm obviously biased since I'm the author, and I don't know if
there's still time):

commit 14dd0f27d7cd56ffae9ecdbe324965073d01a9ff
Author: Nathan Bossart <nathan@postgresql.org>
Date:   Thu Jan 4 16:09:34 2024 -0600

    Add macros for looping through a List without a ListCell.

    Many foreach loops only use the ListCell pointer to retrieve the
    content of the cell, like so:

        ListCell   *lc;

        foreach(lc, mylist)
        {
            int         myint = lfirst_int(lc);

            ...
        }

    This commit adds a few convenience macros that automatically
    declare the loop variable and retrieve the current cell's contents.
    This allows us to rewrite the previous loop like this:

        foreach_int(myint, mylist)
        {
            ...
        }

> An interesting idea would be
> to report all function signature changes in each major release in some
> way.

I think that might be useful, but it very much depends how long that
list gets. If it gets too long I think authors will just try to
compile and only look at the ones that break for them.