From: | Andrew Chernow <ac(at)esilo(dot)com> |
---|---|
To: | Dmitriy Igrishin <dmitigr(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavel Golub <pavel(at)microolap(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: fixing PQsetvalue() |
Date: | 2011-06-23 12:54:46 |
Message-ID: | 4E033796.3080808@esilo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> you are creating as you iterate through. This behavior was
> unnecessary in terms of what libpqtypes and friends needed and may (as
> Tom suggested) come back to bite us at some point. As it turns out,
> PQsetvalue's operation on results that weren't created via
> PQmakeEmptyResult was totally busted because of the bug, so we have a
> unique opportunity to tinker with libpq here: you could argue that you
>
> +1
>
> Exactly at this moment I am thinking about using modifiable
> (via PQsetvalue) PGresult instead of std::map in my C++ library
> for store parameters for binding to executing command.
> I am already designed how to implement it, and I supposed that
> PQsetvalue is intended to work with any PGresult and not only
> with those which has been created via PQmakeEmptyResult...
> So, I am absolutely sure, that PQsetvalue should works with
> any PGresult.
All PGresults are created via PQmakeEmptyPGresult, including libpqtypes.
Actually, libpqtypes calls PQcopyResult which calls PQmakeEmptyPGresult.
It might be better to say a "server" result vs. a "client" result.
Currently, PQsetvalue is broken when provided a "server" generated result.
--
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-23 13:22:40 | Re: [COMMITTERS] pgsql: Make the visibility map crash-safe. |
Previous Message | Pavel Golub | 2011-06-23 12:33:16 | Re: fixing PQsetvalue() |