pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRE: JDBC Driver support for SQLException.getSQLState ()
5+ messages / 3 participants
[nested] [flat]
* RE: JDBC Driver support for SQLException.getSQLState ()
@ 2000-06-30 07:55 Peter Mount <petermount@it.maidstone.gov.uk>
2000-06-30 17:33 ` (no subject) Robert A. Knop Jr. <rknop@lilys.lbl.gov>
0 siblings, 1 reply; 5+ messages in thread
From: Peter Mount @ 2000-06-30 07:55 UTC (permalink / raw)
To: 'Dnesbitt@encryptix.com' <Dnesbitt@encryptix.com>; Peter Mount <petermount@it.maidstone.gov.uk>; +Cc: pgsql-interfaces
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
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* (no subject)
2000-06-30 07:55 RE: JDBC Driver support for SQLException.getSQLState () Peter Mount <petermount@it.maidstone.gov.uk>
@ 2000-06-30 17:33 ` Robert A. Knop Jr. <rknop@lilys.lbl.gov>
2000-06-30 17:59 ` Re: Robert A. Knop Jr. <rknop@lilys.lbl.gov>
0 siblings, 1 reply; 5+ messages in thread
From: Robert A. Knop Jr. @ 2000-06-30 17:33 UTC (permalink / raw)
To: pgsql-interfaces
"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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re:
2000-06-30 07:55 RE: JDBC Driver support for SQLException.getSQLState () Peter Mount <petermount@it.maidstone.gov.uk>
2000-06-30 17:33 ` (no subject) Robert A. Knop Jr. <rknop@lilys.lbl.gov>
@ 2000-06-30 17:59 ` Robert A. Knop Jr. <rknop@lilys.lbl.gov>
2000-06-30 18:20 ` Re: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Robert A. Knop Jr. @ 2000-06-30 17:59 UTC (permalink / raw)
To: pgsql-interfaces
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
>
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re:
2000-06-30 07:55 RE: JDBC Driver support for SQLException.getSQLState () Peter Mount <petermount@it.maidstone.gov.uk>
2000-06-30 17:33 ` (no subject) Robert A. Knop Jr. <rknop@lilys.lbl.gov>
2000-06-30 17:59 ` Re: Robert A. Knop Jr. <rknop@lilys.lbl.gov>
@ 2000-06-30 18:20 ` Tom Lane <tgl@sss.pgh.pa.us>
2000-06-30 23:15 ` Re: Robert A. Knop Jr. <rknop@lilys.lbl.gov>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2000-06-30 18:20 UTC (permalink / raw)
To: Robert A. Knop Jr. <rknop@lilys.lbl.gov>; +Cc: pgsql-interfaces
"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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re:
2000-06-30 07:55 RE: JDBC Driver support for SQLException.getSQLState () Peter Mount <petermount@it.maidstone.gov.uk>
2000-06-30 17:33 ` (no subject) Robert A. Knop Jr. <rknop@lilys.lbl.gov>
2000-06-30 17:59 ` Re: Robert A. Knop Jr. <rknop@lilys.lbl.gov>
2000-06-30 18:20 ` Re: Tom Lane <tgl@sss.pgh.pa.us>
@ 2000-06-30 23:15 ` Robert A. Knop Jr. <rknop@lilys.lbl.gov>
0 siblings, 0 replies; 5+ messages in thread
From: Robert A. Knop Jr. @ 2000-06-30 23:15 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-interfaces
> 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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2000-06-30 23:15 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2000-06-30 07:55 RE: JDBC Driver support for SQLException.getSQLState () Peter Mount <petermount@it.maidstone.gov.uk>
2000-06-30 17:33 ` Robert A. Knop Jr. <rknop@lilys.lbl.gov>
2000-06-30 17:59 ` Re: Robert A. Knop Jr. <rknop@lilys.lbl.gov>
2000-06-30 18:20 ` Re: Tom Lane <tgl@sss.pgh.pa.us>
2000-06-30 23:15 ` Re: Robert A. Knop Jr. <rknop@lilys.lbl.gov>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox