Re: Harmonizing pg_bsd_indent parameter names - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Harmonizing pg_bsd_indent parameter names
Date
Msg-id CAH2-Wzk+awcuYupUtakNgzxVcME=cXOKiFj8u4rM229KFC4w7w@mail.gmail.com
Whole thread Raw
In response to Re: Harmonizing pg_bsd_indent parameter names  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jun 12, 2024 at 5:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > Attached patch harmonizes pg_bsd_indent's function parameter names, so
> > that they match the names used in corresponding function definitions.
>
> Hmm, these aren't really harmonizing inconsistencies, but overruling
> somebody's style decision to leave parameter names out of the extern
> declarations.  That's a style I don't like personally, but some do.

It was my understanding that that was considered just as bad as (or
equivalent to) a mechanical inconsistency. At least for code that was
written from scratch for Postgres (as opposed to vendored in Postgres)
was concerned. We dealt with this during the initial work on bulk
harmonizing code. For example, we made Henry Spencer's regex code
follow Postgres coding standards (in commit bc2187ed).

The regex code was a little different to pg_bsd_indent. There wasn't the same
need to keep up with an upstream. That's why I thought I'd ask about
it before acting.

> We are, at least in theory, trying to stay within hailing distance
> of the upstream; that's the primary reason why we've not touched
> the indentation style of pg_bsd_indent itself.  Still, two lines
> is not going to make much of a difference in whether patches can
> be passed back and forth (whereas reindentation would kill that
> somewhat thoroughly).

Got it.

> Anyway, after chewing on it for a few minutes, no objection here.

Cool. Will push this shortly, then.


--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Sutou Kouhei
Date:
Subject: Re: RFC: adding pytest as a supported test framework
Next
From: "Amonson, Paul D"
Date:
Subject: RE: Proposal for Updating CRC32C with AVX-512 Algorithm.