Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-09-17T18:36:48Z
Lists: pgsql-hackers 
On Sat, Sep 17, 2022 at 11:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, bringing the regex code into line with our standards is fine.
> I don't really see a reason not to do it with the timezone code
> either, as long as there aren't too many changes there.  We are
> carrying a pretty large number of diffs from upstream already.

I'd be surprised if this created more than 3 minutes of extra work for
you when updating the timezone code.

There are a few places where I had to apply a certain amount of
subjective judgement (rather than just mechanically normalizing the
declarations), but the timezone code wasn't one of those places. Plus
there just isn't that many affected timezone related function
declarations, and they're concentrated in only 3 distinct areas.

-- 
Peter Geoghegan

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.