From: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Return results for PQexec vs PQexecP* |
Date: | 2006-05-17 12:45:17 |
Message-ID: | 060ec46407476b085205d56ac51a66e6@biglumber.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200605170839
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iD8DBQFEaxqEvJuQZxSWSsgRAj2TAJ48s7kkzJqb44l6h2XrGxNfckEtcwCg9U8b
ZpZjc6FLtdGu/CZcfsDaPi4=
=dGLJ
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-05-17 12:53:05 | Re: Return results for PQexec vs PQexecP* |
Previous Message | Jonah H. Harris | 2006-05-17 12:25:58 | Re: Compression and on-disk sorting |