Thread: Return results for PQexec vs PQexecP*
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Someone posted something on the DBD::Pg mailing list recently that made me wonder if the user's problem is more of a "don't do that" or something that may be solvable with a libpq or protocol change. Basically, the user has a rule which switches an insert to a select. They then want to run the insert, and pull the resulting tuples from it. This works fine when using PQexec, as it returns the latest result, which is PGRES_TUPLES_OK. However, when using the newer PQexec family (PQexecParams and PQexecPrepared), the only thing returned is PGRES_COMMAND_OK, which prevents the drawing of any subsequent tuples. Can anyone think of an easy way around this (other than forcing PQexec), and if not, is this a problem that needs fixing? It would be nice if PQexec and PQexecParams had the exact same behavior (and ideally, returned TUPLES_OK, even though COMMAND_OK may be more correct). - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200605170839 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFEaxqEvJuQZxSWSsgRAj2TAJ48s7kkzJqb44l6h2XrGxNfckEtcwCg9U8b ZpZjc6FLtdGu/CZcfsDaPi4= =dGLJ -----END PGP SIGNATURE-----
On Wed, May 17, 2006 at 12:45:17PM -0000, Greg Sabino Mullane wrote: > Someone posted something on the DBD::Pg mailing list recently that > made me wonder if the user's problem is more of a "don't do that" > or something that may be solvable with a libpq or protocol change. > > Basically, the user has a rule which switches an insert to a select. > They then want to run the insert, and pull the resulting tuples > from it. This works fine when using PQexec, as it returns the latest > result, which is PGRES_TUPLES_OK. However, when using the newer > PQexec family (PQexecParams and PQexecPrepared), the only thing returned > is PGRES_COMMAND_OK, which prevents the drawing of any subsequent tuples. The main problem with PQexec and co is that they don't really do very well if a single query produces multiple result sets. I'm not sure if it's defined whether you get the first or the last. In any case, if you want all the result sets, you need to be looking at PQsendquery and co. Have a ncie day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Someone posted something on the DBD::Pg mailing list recently that
> made me wonder if the user's problem is more of a "don't do that"
> or something that may be solvable with a libpq or protocol change.
> Basically, the user has a rule which switches an insert to a select.
> They then want to run the insert, and pull the resulting tuples
> from it. This works fine when using PQexec, as it returns the latest
> result, which is PGRES_TUPLES_OK. However, when using the newer
> PQexec family (PQexecParams and PQexecPrepared), the only thing returned
> is PGRES_COMMAND_OK, which prevents the drawing of any subsequent tuples.
I'd call that a "don't do that" issue. The newer protocol is
specifically designed to be more predictable than the old, and that
includes not returning tuples from statements that clearly shouldn't
return anything.
regards, tom lane
On Wed, May 17, 2006 19:53, Martijn van Oosterhout wrote: > The main problem with PQexec and co is that they don't really do very > well if a single query produces multiple result sets. I'm not sure if > it's defined whether you get the first or the last. In any case, if you > want all the result sets, you need to be looking at PQsendquery and co. AFAIK it's well-defined if you send multiple queries in a single string, separated by semicolons: PQexec() returns the result of the last query. Jeroen