Re: useless assignment pointer argument

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Gaetano Mendola <mendola(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: useless assignment pointer argument
Date: 2015-05-29 03:45:24
Message-ID: 15364.1432871124@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2015-05-28 20:14:33 +0000, Gaetano Mendola wrote:
>> src/backend/commands/explain.c:1692
>> src/backend/commands/explain.c:1874
>> src/backend/commands/explain.c:1986
>>
>> there is the following assignment:
>>
>> ancestors = list_delete_first(ancestors);
>>
>> but it has no effect at all being that a function parameter and not used
>> anymore after the assignment itself.

> So? It costs little to nothing, and it'll make it much less likely that
> a stale version of 'ancestors' is used when the code is expanded.

It's completely mistaken to imagine that the statement has no effect:
it does change the underlying List structure, so removing it would be
wrong.

It's true that we could, today, write it as

(void) list_delete_first(ancestors);

but this is not any more clear IMO, and it would fail if the code were
ever changed so that these functions did use the ancestors list after
the point of popping the context they pushed for their children. That
risk outweighs any argument about how deleting the assignment would
quiet some tool or other.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-29 03:55:53 Re: fsync-pgdata-on-recovery tries to write to more files than previously
Previous Message Tom Lane 2015-05-29 03:35:17 Re: auto_explain sample rate