Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group