> On Apr 23, 2026, at 13:19, David Rowley <[email protected]> wrote:
>
> On Wed, 22 Apr 2026 at 17:14, Chao Li <[email protected]> wrote:
>> 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.
>
> Thank you. I pushed those after some adjustments.
>
> While doing that, I did think more on if we should do more of this for
> v20. I keep thinking back to the times when I've had to write 6
> different versions of a patch to back patch to 6 different branches.
> It's rarely that bad, but it sure does make you swear when the 6th
> "git am" fails, especially when you find out that it was for a very
> trivial thing, such as a spelling mistake fix. You really have to
> fight off the temptation of complacency after the first 3 or so failed
> git ams.
>
> A worse category of problems that this particular set of patches could
> cause is no conflict when we want one. I personally always write bug
> fixes for master and back-patch them, but if anyone were to work
> forward to newer versions, then imagine someone adding some code to a
> function that does something with a local variable that's shadowed
> globally. If they forward patch that to a version where the local
> variable has been renamed, everything compiles and might appear to
> work, but it's now the global that's being changed when the new code
> was meant to change the local. Maybe no committers work that way, but
> if they do, it's a real risk.
>
> IMO, without any references to recent bugs that have been fixed due to
> shadowing, then I can't see beyond the fact that this might be more
> likely to cause bugs than to prevent them. As I recall, we were about
> borderline on doing -Wshadow=compatible-local. At least for
> non-compatible variables, I'd expect you'd get a warning or error
> during compilation. For the record, I got motivated for Justin's work
> on the compatible-local due to af7d270dd. I removed a shadowed
> variable which was incorrect. In my view, Justin Pryzby's proposal to
> do something about this was well timed. I'm not seeing the same thing
> happen here. Maybe I missed it?
>
> David
Hi David,
Thank you very much for accepting this v19-only patch.
I helped prepare back-patch diff files for [1] today, from v10 to v18. It was
only a tiny change, but I still ended up with 3 diff files across 9 branches,
which was quite painful. I can understand that, as a committer, you probably
run into that kind of pain regularly, and would prefer to avoid adding more of
it.
I’ll hold off on the rest of this cleanup unless there is a concrete reason to
revisit it in the future.
[1] https://postgr.es/[email protected]
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
