public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Chao Li <[email protected]>
To: Postgres hackers <[email protected]>
Subject: Re: Cleanup shadows variable warnings, round 1
Date: Fri, 28 Nov 2025 11:11:04 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEoWx2kQ2x5gMaj8tHLJ3=jfC+p5YXHkJyHrDTiQw2nn2FJTmQ@mail.gmail.com>
References: <CAEoWx2kQ2x5gMaj8tHLJ3=jfC+p5YXHkJyHrDTiQw2nn2FJTmQ@mail.gmail.com>
On 28/11/2025 10:16, Chao Li wrote:
> Hi Hackers,
>
> While reviewing [1], it makes me recall an experience where I had a
> patch ready locally, but CommitFest CI failed with a shadows-variable
> warning. Now I understand that -Wall doesn't by default enable -Wshadows
> with some compilers like clang.
>
> I did a clean build with manually enabling -Wshadow and
> surprisingly found there are a lot of such warnings in the current code
> base, roughly ~200 occurrences.
>
> As there are too many, I plan to fix them all in 3-4 rounds. For round 1
> patch, I'd see any objection, then decide if to proceed more rounds.
I don't know if we've agreed on a goal of getting rid of all shadowing,
it's a lot of code churn. I agree shadowing is often confusing and
error-prone, so maybe it's worth it.
On the patch itself:
In some of the cases, I think we should rename the global / outer-scoped
variable instead of the local variable. For example, it's pretty insane
that we apparently have a global variable called 'days'. :-)
Let's think a little harder about the new names. For example:
> @@ -1274,8 +1274,8 @@ execute_extension_script(Oid extensionOid, ExtensionControlFile *control,
> Datum old = t_sql;
> char *reqextname = (char *) lfirst(lc);
> Oid reqschema = lfirst_oid(lc2);
> - char *schemaName = get_namespace_name(reqschema);
> - const char *qSchemaName = quote_identifier(schemaName);
> + char *schemaname = get_namespace_name(reqschema);
> + const char *qSchemaName = quote_identifier(schemaname);
> char *repltoken;
>
> repltoken = psprintf("@extschema:%s@", reqextname);
Having two local variables that only differ in case is also confusing.
We're using the 'req*' prefix here for the other variables, so I think
e.g. 'reqSchemaName' would be a good name here.
(I didn't go through the whole patch, these were just a few things that
caught my eye at quick glance)
- Heikki
view thread (30+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Cleanup shadows variable warnings, round 1
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox