Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c
Date: 2015-06-26 14:21:59
Message-ID: 25107.1435328519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jun 26, 2015 at 9:49 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> It takes about three seconds to mark it as ignored which will hide it
>> going forward.

> So what? That doesn't help if someone *else* sets up a Coverity run
> on this code base, or if say Salesforce sets up such a run on their
> fork of the code base. It's much better to fix the problem at the
> root.

The problem with that is allowing Coverity, which in the end is not magic
but just another piece of software with many faults, to define what is a
"problem". In this particular case, the only effect of the change that
I can see is to make the code less flexible, and less robust against a
fairly obvious type of future change. So I'm not on board with removing
if-guards just because Coverity thinks they are unnecessary.

I agree that the correct handling of this particular case is to mark it
as not-a-bug. We have better things to do.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-06-26 14:26:58 Re: Should we back-patch SSL renegotiation fixes?
Previous Message Heikki Linnakangas 2015-06-26 14:13:42 Re: GIN: Implementing triConsistent and strategy number