Re: Error in recent pg_dump change (coverity)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Error in recent pg_dump change (coverity)
Date: 2006-05-28 16:19:10
Message-ID: 17874.1148833150@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Sun, May 28, 2006 at 12:00:33PM -0400, Tom Lane wrote:
>> Another possibility is to just MemSet the whole PGresult struct
>> to zeroes before free'ing it.

> Probably better actually, since by setting ntups to zero also,
> PQgetvalue will return a warning (row number out of range) rather than
> segfaulting...

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-05-28 16:47:35 Re: Error in recent pg_dump change (coverity)
Previous Message Martijn van Oosterhout 2006-05-28 16:13:34 Re: Error in recent pg_dump change (coverity)