FAQ
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

Search Discussions

  • Martijn van Oosterhout at May 17, 2006 at 12:53 pm

    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.
  • Jeroen T. Vermeulen at May 17, 2006 at 3:08 pm

    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
  • Tom Lane at May 17, 2006 at 2:28 pm

    "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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 17, '06 at 12:44p
activeMay 17, '06 at 3:08p
posts4
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase