Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c
Date
Msg-id 25107.1435328519@sss.pgh.pa.us
Whole thread Raw
In response to Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c  (Robert Haas <robertmhaas@gmail.com>)
Re: Nitpicking: unnecessary NULL-pointer check in pg_upgrade's controldata.c  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jun 26, 2015 at 9:49 AM, Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: GIN: Implementing triConsistent and strategy number
Next
From: Robert Haas
Date:
Subject: Re: Should we back-patch SSL renegotiation fixes?