Re: 09.03.0100 cursor failures on various architectures

On 02/12/2014 12:45 PM, Christoph Berg wrote:
> s390x has that problem, plus an additional diff for positioned-update:
>
> *** /«PKGBUILDDIR»/test/expected/positioned-update.out    Tue Dec 17 14:16:00 2013
> --- /«PKGBUILDDIR»/test/results/positioned-update.out    Wed Feb  5 17:09:31 2014
> ***************
> *** 13,19 ****
>    2    2
>    3    3
>    4    4
> ! 105    5
>    7    7
>    8    8
>    9    9
> --- 13,19 ----
>    2    2
>    3    3
>    4    4
> ! 5    5
>    7    7
>    8    8
>    9    9

This is also an issue related to endianess and mismatched datatypes. The
problem is with the SQLBindCol call. Positioned-update test does this:

long    colvalue;
...
rc = SQLBindCol(hstmt, 1, SQL_C_LONG, &colvalue, 0, &indColvalue);

And SQLBindCol does this:

case SQL_C_SLONG:
case SQL_C_LONG:
   len = 4;
   if (bind_size > 0)
     *((SQLINTEGER *) rgbValueBindRow) = atol(neut_str);
   else
     *((SQLINTEGER *) rgbValue + bind_row) = atol(neut_str);
   break;

So, SQLBindPos assumes that the target variable is of type SQLINTEGER,
when the caller indicated that it's SQL_C_LONG. My gut reaction is that
that's bogus - if the caller said that it's of C-type long, by passing
SQL_C_LONG, we should believe that, rather than assume that SQL_C_LONG
means SQLINTEGER. I found a brief thread on this on the unixodbc-dev
mailing list:

http://mailman.unixodbc.org/pipermail/unixodbc-dev/2005-March/000396.html

The same author raised the issue also on the psqlodbc mailing list:

http://www.postgresql.org/message-id/flat/4224F80D.2080103@kkcsm.net#4224F80D.2080103@kkcsm.net

Microsoft has a table of SQL_C_* codes and which C types they correspond
to (http://msdn.microsoft.com/en-us/library/ms714556%28v=vs.85%29.aspx),
but that's not taking into account other operating systems where the
widths of C integer types are different. We didn't explicitly discuss in
that psqlodbc mailing list thread if it's sane that SQL_C_LONG means a
32-bit integer regardless of how wide the C "long" type actually is.
While I think the way the code currently works is wrong, it's probably
too late to change that. It would be interesting to know how other ODBC
drivers have interpreted that.

Conclusion: I've committed a patch to change the test case to use
SQLINTEGER instead of long as the variable's datatype. I also added an
explicit test case for SQLBindCol.

- Heikki