Return results for PQexec vs PQexecP*

Поиск
Список
Период
Сортировка
От Greg Sabino Mullane
Тема Return results for PQexec vs PQexecP*
Дата
Msg-id 060ec46407476b085205d56ac51a66e6@biglumber.com
обсуждение исходный текст
Ответы Re: Return results for PQexec vs PQexecP*  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Return results for PQexec vs PQexecP*  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
-----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-----




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: Compression and on-disk sorting
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Return results for PQexec vs PQexecP*