Re: [Proposal] Level4 Warnings show many shadow vars - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [Proposal] Level4 Warnings show many shadow vars
Date
Msg-id CA+TgmoZsM04VCKn4n8dsXxg_s8drPUHUafshG=P0edVjUS3Gew@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Level4 Warnings show many shadow vars  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [Proposal] Level4 Warnings show many shadow vars  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 9, 2019 at 10:23 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Sun, Dec 8, 2019 at 1:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I don't think I'm actually on board with the goal here.
> > I don't know what to do about the RedoRecPtr mess, but surely
> > subscriptioncmds.c's use of synchronous_commit as a char * when it's
> > already exists as a global variable of type int is not good practice.
> Well, again, this is a case-by-case question.  I tend to agree that
> changing that usage in subscriptioncmds.c might be a good idea.
> That doesn't mean I need to be on board with wholesale removal
> of shadowing warnings.

I agree that those things are different, but I'm not sure I understand
the nuances of your view. I think my view is that if something in our
code is shadowing something else in our code, that's probably
something we ought to look at fixing. If you disagree, I'd be curious
to know why; I suspect that, as in this case, such cases are just
creating a risk of confusion without any real benefit. To me, the grey
area is in conflicts between stuff in our code and stuff in system
header files. I'm not sure I'd want to try to have precisely 0
conflicts with every crazy decision by every OS / libc maintainer out
there, and I suspect on that point at least we are in agreement.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: global / super barriers (for checksums)
Next
From: Mark Dilger
Date:
Subject: Re: Questions about PostgreSQL implementation details