Обсуждение: 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. +