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*).
On Fri, 30 Jun 2000, Robert A. Knop Jr. wrote:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > "Robert A. Knop Jr." <rknop(at)lilys(dot)lbl(dot)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.
> 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?
In response to
- at 2000-06-30 17:33:09 from Robert A. Knop Jr.
- Re: at 2000-06-30 18:20:28 from Tom Lane
pgsql-interfaces by date
|Next:||From: Tom Lane||Date: 2000-06-30 18:20:28|
|Subject: Re: |
|Previous:||From: Robert A. Knop Jr.||Date: 2000-06-30 17:33:09|