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(dot)2080103(at)kkcsm(dot)net#4224F80D(dot)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