Re: Cleanup shadows variable warnings, round 1

> On Apr 21, 2026, at 21:51, Álvaro Herrera <alvherre@kurilemu.de> wrote:
> 
> On 2026-Apr-21, David Rowley wrote:
> 
>> On Tue, 21 Apr 2026 at 19:02, Chao Li <li.evan.chao@gmail.com> wrote:
>>> PFA v8 - rebased and fixed a few new occurrences.
>> 
>> Which of these are new to v19?  Can you separate those ones out? IMO,
>> we should commit at least those, as those won't cause any backpatching
>> pain.
> 
> I agree.  The others are v20 material.
> 

Sounds reasonable.

The attached new v1 patch fixes the v19-only shadow warnings. There are not many. I strictly limited it to warnings newly introduced in v19, without touching any pre-existing ones, even where an old occurrence is very close to a new one.

I intentionally left out one occurrence in ruleutils.c:
```
ruleutils.c:13100:23: warning: declaration shadows a local variable [-Wshadow]
 13100 |                                                 deparse_context context = {0};
       |                                                                 ^
ruleutils.c:12955:67: note: previous declaration is here
 12955 | get_from_clause_item(Node *jtnode, Query *query, deparse_context *context)
       |                                                                   ^
1 warning generated.
```

I saw there is a thread [1] that will remove this deparse_context context = {0};, so I skipped this one to avoid a potential conflict.

Besides the patch file, I am also attaching three files for reference:

* v18-shadow-warnings.txt - all shadow warnings from branch REL_18_STABLE
* v19-shadow-warnings-master.txt - all shadow warnings from current master (9d3e094f12c)
* v19-shadow-warnings-patched.txt - all shadow warnings after applying this v1 patch

Except for the one in ruleutils.c, v19-shadow-warnings-patched.txt is a pure subset of v18-shadow-warnings.txt. You don't need to read these large files; they are attached only for reference.

I will recreate the previous patch set for v20.

> 
> Specifically about 0003 (v20 material for sure, as this is ancient
> code), I don't like this patch very much.  I wonder if it would be
> possible to do away with the idea of using these codeFragment things
> without introducing a performance issue here.  Is that doable by turning
> these macros into static functions?
> 

Okay, I will remove 0003 from this patch set, and use a separate patch to try converting the macros to static functions.

[1] http://postgr.es/m/CAHg+QDcLVa2iBnggkHxY4itZbXtDMfsYHEjnCUYe9hNbnxDi-w@mail.gmail.com

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/