Re: libpq-fe: PQgetvalue() ?
Hi,
I'm replying to a thread that is two years old (
http://archives.postgresql.org/pgsql-sql/2004-10/msg00099.php
), but:
Tom Lane wrote at Fri, 15 Oct 2004 10:21:29 -0400:
Christoph Haller <ch ( at ) rodos ( dot ) fzk ( dot ) de> writes:
You cannot PQclear(pgresult_varible) while cstring_varible is in use.
You do not need to free cstring_variable, PQclear(pgresult_varible)
will do.
I personally prefer to allocate local memory, "strcpy" PQgetvalue,
and then PQclear. But that's a matter of taste, I suppose.
That is surely overkill.
PQgetvalue doesn't allocate new memory for its result. The docs are
reasonably clear, I thought:
The pointer returned by PQgetvalue points to storage that is part
of the PGresult structure. One should not modify the data it points
to, and one must explicitly copy the data into other storage if it
is to be used past the lifetime of the PGresult structure itself.regards, tom lane
Shouldn't the return type of "PQgetvalue" be "const char*", then?
Maybe its just me...
regards,
Danny Milosavljevic
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Danny Milosavljevic wrote:
Hi,
I'm replying to a thread that is two years old (
http://archives.postgresql.org/pgsql-sql/2004-10/msg00099.php
), but:Tom Lane wrote at Fri, 15 Oct 2004 10:21:29 -0400:
Christoph Haller <ch ( at ) rodos ( dot ) fzk ( dot ) de> writes:
You cannot PQclear(pgresult_varible) while cstring_varible is in use.
You do not need to free cstring_variable, PQclear(pgresult_varible)will do.
I personally prefer to allocate local memory, "strcpy" PQgetvalue,
and then PQclear. But that's a matter of taste, I suppose.That is surely overkill.
PQgetvalue doesn't allocate new memory for its result. The docs are
reasonably clear, I thought:The pointer returned by PQgetvalue points to storage that is part
of the PGresult structure. One should not modify the data it points
to, and one must explicitly copy the data into other storage if it
is to be used past the lifetime of the PGresult structure itself.regards, tom lane
Shouldn't the return type of "PQgetvalue" be "const char*", then?
Maybe its just me...
regards,
Danny Milosavljevic
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
This has been saved for the 8.3 release:
Danny Milosavljevic wrote:
Shouldn't the return type of "PQgetvalue" be "const char*", then?
The pluses and minuses of const-ifying libpq's API have been discussed
before. If we were working in a green field we'd no doubt do it, but
I'm not sure that users would thank us for breaking their existing
working code. Adding a "const" to a function result value has direct
impact on calling applications...
regards, tom lane
Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
This has been saved for the 8.3 release:
Danny Milosavljevic wrote:
Shouldn't the return type of "PQgetvalue" be "const char*", then?
The pluses and minuses of const-ifying libpq's API have been discussed
before. If we were working in a green field we'd no doubt do it, but
I'm not sure that users would thank us for breaking their existing
working code. Adding a "const" to a function result value has direct
impact on calling applications...
OK, I was afraid of that. Removed from the 8.3 queue.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +