Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings

Tom Lane <tgl@sss.pgh.pa.us>

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
Date: 2025-07-15T23:52:05Z
Lists: pgsql-hackers
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



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Clarify the ra != rb case in compareJsonbContainers().

  2. Silence uninitialized-value warnings in compareJsonbContainers().