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