Re: [INTERFACES] Counting updates with libpq - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: [INTERFACES] Counting updates with libpq
Date
Msg-id 6485.920908058@sss.pgh.pa.us
Whole thread Raw
In response to Re: [INTERFACES] Counting updates with libpq  (Michael Meskes <meskes@postgresql.org>)
Responses Re: [INTERFACES] Counting updates with libpq
List pgsql-interfaces
Michael Meskes <meskes@postgreSQL.org> writes:
>> No.  PQntuples() is the number of rows in the returned result.  It will
>> always be zero if the SQL command was not SELECT (or FETCH).

> I'm afraid this is incorrect. I tried it on an insert (via exec sql execute
> immediate) and it got the correct result.

No, I'm afraid *you* are incorrect: a test program like

    res = PQexec(conn, "INSERT INTO test SELECT * FROM test");
    if (PQresultStatus(res) != PGRES_COMMAND_OK)
    {
        fprintf(stderr, "INSERT command failed\n");
        PQclear(res);
        exit_nicely(conn);
    }

    printf("INSERT result PQntuples = %d\n", PQntuples(res));
    printf("INSERT result PQcmdTuples = %s\n", PQcmdTuples(res));

produces the expected results (ntuples = 0, cmdTuples = number of
inserted rows) for either variant of INSERT.

It seems likely that ecpg is interposing some additional behavior
not seen in bare libpq, although I'm at a loss to guess what.
Surely ecpg wouldn't be trying to implicitly fetch the inserted rows?

            regards, tom lane

pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: [INTERFACES] copy command & null datetime
Next
From: Laurent TASTET
Date:
Subject: I can't use pgaccess !!