From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Return results for PQexec vs PQexecP* |
Date: | 2006-05-17 14:27:54 |
Message-ID: | 19727.1147876074@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Greg Sabino Mullane" <greg(at)turnstep(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-17 14:31:24 | Re: pg_dump and backslash escapes |
Previous Message | Andrew Dunstan | 2006-05-17 14:27:15 | Re: PL/pgSQL 'i = i + 1' Syntax |