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
>
>
