From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: shadow variables - pg15 edition |
Date: | 2022-08-18 00:39:02 |
Message-ID: | Yv2KJiDhnqrZR7VE@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 18, 2022 at 08:49:14AM +1000, Peter Smith wrote:
> I'd started looking at these [1] last year and spent a day trying to
> categorise them all in a spreadsheet (shadows a global, shadows a
> parameter, shadows a local var etc) but I became swamped by the
> volume, and then other work/life got in the way.
>
> +1 from me.
A lot of the changes proposed here update the code so as the same
variable gets used across more code paths by removing declarations,
but we have two variables defined because both are aimed to be used in
a different context (see AttachPartitionEnsureIndexes() in tablecmds.c
for example).
Wouldn't it be a saner approach in a lot of cases to rename the
shadowed variables (aka the ones getting removed in your patches) and
keep them local to the code paths where we use them?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-08-18 01:09:46 | Re: Assertion failure on PG15 with modified test_shm_mq test |
Previous Message | Andres Freund | 2022-08-18 00:08:42 | Re: Assertion failure on PG15 with modified test_shm_mq test |