Re: Error in recent pg_dump change (coverity) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Error in recent pg_dump change (coverity)
Date
Msg-id 20060528173832.GC15766@surnet.cl
Whole thread Raw
In response to Re: Error in recent pg_dump change (coverity)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Error in recent pg_dump change (coverity)  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Error in recent pg_dump change (coverity)  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Tom Lane wrote:
> >> Hm.  But I think we'd *like* it to segfault; the idea is to make the
> >> user's programming error as obvious as possible.  Is it worth the
> >> trouble to just zero out the pointer members of the PGresult?
> 
> > There are only five of them; four need to be zeroed out.
> 
> Works for me.  Please commit, as I'm about to do some further work in
> those files and would rather not have to merge ...

Done.  They were actually four, not five.  The one I mistakingly though
was one was the notice processor hooks.

The case Martijn was saying would be warned about by the memset
approach, setting ntuples to 0, would actually be handled as a segfault,
because functions like check_field_number actually follow
res.noticeHooks pointer!  ISTM we would just segfault at that point.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error in recent pg_dump change (coverity)
Next
From: Bruce Momjian
Date:
Subject: Re: Error in recent pg_dump change (coverity)