Re:

Wait -- ignore me, I think I was wrong.

I still can't figure out where my memory leak is coming in, but it seems
to be either something so dumb in my code that I can't see it, or
something obscure having to do with the operator= method of the C++ STL
"string" class (when setting a string equal to a char*).

-Rob

On Fri, 30 Jun 2000, Robert A. Knop Jr. wrote:

> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> 
> > "Robert A. Knop Jr." <rknop@lilys.lbl.gov> writes:
> > > If one uses libpq functions such as PQfname, should one free the
> > > returned character string?
> > 
> > No.  Unless the doc for the function explicitly says you should free
> > its result, it's a pointer into libpq-managed space.
> 
> Huh.
> 
> Experience contradicts this.  I was getting back the results from
> PQgetvalue(), and copying them to a C++ string.  I wasn't bothering to
> free what I got back from PQgetvalue(), figuring that based on this,
> anything that PQgetvalue() was pointing at would be freed I called
> PQclear() on the PGresult structure I had passed to PQgetvalue().  In so
> doing, I had a memory leak.
> 
> I rewrote the thing explicitly freeing everything I got back from
> PQfname() and PQgetvalue().  The memory leak was gone, and I didn't get
> any segfaults or crashes.
> 
> Although this contradicts the documentation on PQgetvalue(), and also
> what was said here, based on experience it looks like that in fact one
> *must* free the character arrays one gets back from those functions.
> 
> Is there a Postgres developer who can confirm this one way or the other?
> This should defintely be documented in the libpq documentation.
> 
> Note that I'm using Postgres 6.5.2 -- has this behavior changed with
> version 7?
> 
> -Rob
> 
>