From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Meskes <meskes@postgreSQL.org>
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Counting updates with libpq
Date: Mon, 08 Mar 1999 10:47:38 -0500
Message-ID: <6485.920908058@sss.pgh.pa.us> (raw)
In-Reply-To: <19990308084647.C227@gmx.net>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, meskes@postgreSQL.org
Subject: Re: [INTERFACES] Counting updates with libpq
In-Reply-To: <6485.920908058@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox