Re: Cleanup shadows variable warnings, round 1

On 4/22/2026 1:14 PM, Chao Li wrote:
>
>> On Apr 21, 2026, at 21:51, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>>
>> On 2026-Apr-21, David Rowley wrote:
>>
>>> On Tue, 21 Apr 2026 at 19:02, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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/
>
>
>
>
The v1 patch LGTM, and “make check-world” passed after applying it.

Regards,
Yuchen Li