Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings
От | Tom Lane |
---|---|
Тема | Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings |
Дата | |
Msg-id | 1144304.1752623525@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings
|
Список | 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
В списке pgsql-hackers по дате отправления: