From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Andres Freund <andres@anarazel.de>,
        Dmitry Mityugov <d.mityugov@postgrespro.ru>,
        pgsql-hackers@postgresql.org
Subject: Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings
In-reply-to: 
 <CAH2-Wzk-LH8Ln235hB4Y39EDFE6Bvb2bxKxMn_Ru4GjJNxTHnA@mail.gmail.com>
References: <0c623e8a204187b87b4736792398eaf1@postgrespro.ru>
 <82868.1752342174@sss.pgh.pa.us>
 <ib5yhkzseb27icjpz5p6wqgppaoa2nhjzj3ldx23d65ehciwin@um6dx2bpxux3>
 <CAH2-WzkXwnY=cNGDODOyW=AhT4H8Rj7MiOk3mcN=Ua2w8C=RZg@mail.gmail.com>
 <1138043.1752620290@sss.pgh.pa.us>
 <CAH2-WzmS84KwUuZaP-ha7YwCCatDbQHcEjUGLDuihC5B=kxc1A@mail.gmail.com>
 <1141814.1752622038@sss.pgh.pa.us>
 <CAH2-Wzk-LH8Ln235hB4Y39EDFE6Bvb2bxKxMn_Ru4GjJNxTHnA@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Tue, 15 Jul 2025 19:30:21 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1144303.1752623525.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 15 Jul 2025 19:52:05 -0400
Message-ID: <1144304.1752623525@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1144304.1752623525%40sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Tue, Jul 15, 2025 at 7:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'd be a bit worried about
>> creating a back-patching mine-field.  But maybe these are all
>> in spots we're unlikely to touch?

> That seems like much less of a problem for a purely subtractive change
> such as this.

Not really convinced.  Taking a sample at random (from ExecRenameStmt
in alter.c):

                return address;
            }

        default:
            elog(ERROR, "unrecognized rename stmt type: %d",
                 (int) stmt->renameType);
            return InvalidObjectAddress;    /* keep compiler happy */
    }
}

Assume we remove the "return InvalidObjectAddress;" line and later
need to back-patch a change touching this area.

If we were to add/change something in front of the "default:", we're
probably fine because the "default:" and the elog() would be enough
context lines to allow patch(1) to figure out where to put the
addition/change.  However, if we wanted to add something after the
switch construct, we'd get an apply failure and have to fix it
manually --- or worse, patch(1) would apply the delta in the
wrong place.

I'm not sure how likely such scenarios are, but it doesn't seem
zero-risk.  And if we do hundreds of these, the odds of trouble
will increase.

			regards, tom lane