Re: Remove redundant assignment of a variable in function AlterPublicationTables

Поиск
Список
Период
Сортировка
От Peter Smith
Тема Re: Remove redundant assignment of a variable in function AlterPublicationTables
Дата
Msg-id CAHut+Pua62ewP+LL+Use4eML2ssi28wPoz=koJpQWmZk2KPrNQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Remove redundant assignment of a variable in function AlterPublicationTables  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Remove redundant assignment of a variable in function AlterPublicationTables
Список pgsql-hackers
On Thu, Aug 21, 2025 at 10:11 AM Michael Paquier <michael@paquier.xyz> wrote:
...
>
> It does not matter to leave the code as is.  We have a bunch of these
> depending on how people feel on the day when they implement something.
>

Hi Michael.

Some declaration assignments may be arbitrary, but I think 'isNull'
follows a well-established pattern in PG source.

FWIW, here are some search results:

Search for "&isNull[,)]" ==> ~427

Search for declarations assignments like
"bool\s*isNull\s*=\s*(true|false)" ==> ~12

Of those 12 declarations, I found only ~4 that go on to pass
unconditionally to functions by &isNull:
- AlterPublicationTables() in publicationcmds.c (this patch)
- percentile_disc_multi_final() in orderedsetaggs.c
- CatalogCacheComputeTupleHashValue() in catcache.c
- pltcl_returnnext() in pltcl.c

To summarise:
Only ~4 places are redundantly assigning isNull values before calling
functions that use &isNull.
But ~400 function calls that are passing &isNull do not pre-assignment
of that variable.

Choosing to keep this patch would be consistent with 99% of existing examples.

~~

Aside:

Of course, I recognise this is a small change that may not seem worth
the discussion overhead. However, I feel it is indicative of a problem
that's worth addressing.

During patch reviews, when I suggest fixing small issues alongside the
main changes (e.g. "let's clean up this redundant assignment while
we're here"), the typical response is that unrelated changes should be
submitted separately to keep patches focused.

But when these minor fixes are submitted as standalone patches,
they're often dismissed as too trivial to be worth the review effort
and commit overhead.

This creates a catch-22 where small but legitimate improvements never
get addressed. They fall into a gap where changes are either "too
small to include" or "too small to stand alone." This leaves valid
improvements in limbo indefinitely.

Do you have any advice for how to handle such changes?

======
Kind Regards,
Peter Smith.
Futjisu Australia



В списке pgsql-hackers по дате отправления: