Обсуждение: RE: JDBC Driver support for SQLException.getSQLState ()
I'm about to compile the todo list ready for me to resume work. However, as I'm still settling in to a new home (I've yet to setup net access there), I'm not going to start for at least a couple of weeks. Peter -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council -----Original Message----- From: Dnesbitt@encryptix.com [mailto:Dnesbitt@encryptix.com] Sent: Thursday, June 29, 2000 11:49 PM To: petermount@it.maidstone.gov.uk Cc: Dnesbitt@encryptix.com; pgsql-interfaces@postgresql.org Subject: RE: [INTERFACES] JDBC Driver support for SQLException.getSQLState () Peter, What level of priority does this have on the todo list? Will support be added anytime soon? Regards, //Dave > -----Original Message----- > From: Peter Mount [mailto:petermount@it.maidstone.gov.uk] > Sent: Thursday, June 29, 2000 12:47 AM > To: 'Dnesbitt@encryptix.com'; pgsql-interfaces@postgresql.org > Subject: RE: [INTERFACES] JDBC Driver support for > SQLException.getSQLState () > > > Not yet. > > -- > Peter Mount > Enterprise Support > Maidstone Borough Council > Any views stated are my own, and not those of Maidstone > Borough Council > > > -----Original Message----- > From: Dnesbitt@encryptix.com [mailto:Dnesbitt@encryptix.com] > Sent: Wednesday, June 28, 2000 5:38 PM > To: pgsql-interfaces@postgresql.org > Cc: Dnesbitt@encryptix.com > Subject: [INTERFACES] JDBC Driver support for > SQLException.getSQLState() > > > > > Does the PostgreSQL JDBC Driver have support for the > getSQLState() method > > of the SQLException? > > > > Regards, > > //Dave >
"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
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 > >
"Robert A. Knop Jr." <rknop@lilys.lbl.gov> writes:
>>>> 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 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.
I don't understand how. In recent versions, not only is the pointer
you get back not a freshly-malloced chunk, it's not a malloc chunk at
all, but a pointer into the middle of a much larger malloc chunk.
You must have an extremely forgiving malloc library, one wherein free()
doesn't crash if handed a pointer that doesn't point at a malloc chunk.
>> Is there a Postgres developer who can confirm this one way or the other?
I am a Postgres developer, and if you don't want to take my word for it,
read the source code. src/interfaces/libpq/fe-exec.c sez:
char *
PQgetvalue(const PGresult *res, int tup_num, int field_num)
{ if (!check_tuple_field_number("PQgetvalue", res, tup_num, field_num)) return NULL; return
res->tuples[tup_num][field_num].value;
}
char *
PQfname(const PGresult *res, int field_num)
{ if (!check_field_number("PQfname", res, field_num)) return NULL; if (res->attDescs) return
res->attDescs[field_num].name; else return NULL;
}
Actual loading of the PGresult structure is elsewhere in the same file,
but you can certainly see that you're not getting your very own copy
back here.
regards, tom lane
> I am a Postgres developer, and if you don't want to take my word for it, > read the source code. src/interfaces/libpq/fe-exec.c sez: Hi -- sorry, I didn't realize you were, and it was entirely my mistake about what the libpq functions did. In the end, my problem was mixing code compiled with -fPIC and code complied without it. That seemed to generate a memory leak in code which was actually disconnected from Postgres. However, diagnosing it turned out to be very difficult given that the code itself was fine, and after some tests I incorrectly came to the conclusion about what PQgetvalue() returned. (I still don't know why I didn't get core dumps, but probably what happened was that my test didn't try to free as much as I had thought it did.) Thanks, -Rob
"Robert A. Knop Jr." <rknop@lilys.lbl.gov> writes:
> In the end, my problem was mixing code compiled with -fPIC and code
> complied without it.
Oooh, that's nasty. I've not seen problems with that combination
myself --- must be a platform-specific gotcha. But I'll keep an
eye out for it in future.
regards, tom lane