Regression in psqlodbc 9.1.2 in SQLRowCount()

Hello.

Our code does a bunch of selects, inserts and updates, including an
insert within a transaction that looks like:

  insert into foo values (?, ?, ?, ?, ?, ?, ?, ?)

where the parameters are integers, strings and timestamps. We then use
SQLRowCount() to confirm that one row was inserted.

With the 9.1.2 driver, if one of the string parameters is five
characters long then I get -1 for the affected rows in SQLRowCount().
(I'm not sure that the string length is anything to do with it, but it
causes the problem without fail, and it appears to work fine with any
other length of string.) I've confirmed via Wireshark that the number
of affected rows is indeed 1 and is being sent to the client from the
PostgreSQL server.

Like Vadim Zeitlin:
http://www.postgresql.org/message-id/E1UQdZr-00073b-2A@smtp.tt-solutions.com
I've concluded that the problem occurs if and only if this change:

diff a/statement.h b/statement.h
--- a/statement.h
+++ b/statement.h0
@@ -440,7 +440,7 @@ do { \
        if (PREPARED_TEMPORARILY == (a)->prepared) \
        { \
                SC_set_prepared(a, ONCE_DESCRIBED); \
-               if (!SC_IsExecuting((a))) \
+               if (FALSE && !SC_IsExecuting((a))) \
                { \
                        QResultClass    *res = SC_get_Curres((a)); \
                        if (NULL != res && !res->dataFilled && !QR_is_fetching_t

is in the driver, and that the problem is not present in the current
master (fa29bfe) of Heikki Linnalangas' repository because the
affected code has disappeared (commit 30b201b). As with Vadim,
I'm not sufficiently familiar with that code to comment further.

Our code works fine with the 9.1.1 driver and with the 8.4.2 driver,
with SQL Server and with Oracle. It compiles without warnings on 19
different platforms at the highest warning level and runs without
Valgrind warnings. It's been in production around the world for years
(albeit mainly on SQL Server) without problems. It /might/ be a bug
in our code, but I'm not convinced.

I'm running this on a 64-bit Linux box with a 64-bit app (and hence
obviously a 64-bit driver). The problem occurs with both the ANSI and
Unicode drivers.

I've attached some sanitised mylogs, both from the 9.1.2 driver, for
cases that worked (not 5 char string) and didn't (5 char string).

(I appreciate the fact that I benefit from your efforts for free, but
I'd also echo Vadim's comments regarding the fact that the change that
broke the driver didn't compile, and the consequent conclusions that
one can draw regarding the amount of testing that might have been
undertaken before committing. It would be a shame if your efforts
ended up unused due to a lack of confidence in the quality /
regression testing / change control of a core piece of functionality.)

Regards,
Geoff.