Horton

Re: Making C function declaration parameter names consistent with corresponding definition names

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

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-09-16T23:49:51Z
Lists: pgsql-hackers 
Peter Geoghegan <pg@bowt.ie> writes:
> It's possible to configure the clang-tidy tooling to tolerate various
> inconsistencies, below some kind of threshold -- it is totally
> customizable. But I think that a strict, simple rule is the way to go
> here.

Agreed; I see no need to tolerate any inconsistency.

> (Though without creating busy work for committers that don't
> want to use clang-tidy all the time.)

Yeah.  I'd be inclined to handle it about like cpluspluscheck:
provide a script that people can run from time to time, but
don't insist that it's a commit-blocker.  (I wouldn't be unhappy
to see the cfbot include this in its compiler warnings suite,
though, once we get rid of the existing instances.)

			regards, tom lane

Commits

  1. Harmonize parameter names in pg_dump/pg_dumpall.

  2. Harmonize parameter names in contrib code.

  3. Harmonize more lexer function parameter names.

  4. Harmonize parameter names in ecpg code.

  5. Harmonize lexer adjacent function parameter names.

  6. Harmonize more parameter names in bulk.

  7. Harmonize parameter names in storage and AM code.

  8. Harmonize heapam and tableam parameter names.

  9. Consistently use named parameters in timezone code.

  10. Consistently use named parameters in regex code.

  11. Harmonize reorderbuffer parameter names.

  12. Make check_usermap() parameter names consistent.