From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgreSQL(dot)org> |
Cc: | pgsql-interfaces(at)postgreSQL(dot)org |
Subject: | Re: [INTERFACES] Counting updates with libpq |
Date: | 1999-03-08 15:47:38 |
Message-ID: | 6485.920908058@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Michael Meskes <meskes(at)postgreSQL(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Laurent TASTET | 1999-03-08 17:10:56 | I can't use pgaccess !! |
Previous Message | Tom Lane | 1999-03-08 14:58:16 | Re: [INTERFACES] copy command & null datetime |