Re: 09.03.0100 cursor failures on various architectures - Mailing list pgsql-odbc

(2014/02/28 18:53), Heikki Linnakangas wrote:
> On 02/27/2014 01:30 PM, Hiroshi Inoue wrote:
>> (2014/02/26 17:51), Heikki Linnakangas wrote:
>>> It works on Windows, because sizeof(long) == sizeof(SQLINTEGER) on
>>> Windows, and it works with unixODBC because unixODBC defines SQL_C_LONG
>>> as 32-bits regardless of the actual width of "long".
>>
>> The ODBC spec clearly mentiones that SQL_C_LONG corresponds to
>> SQLINTEGER from the first.
>
> It also clearly says that the native C type corresponding SQL_C_LONG and
> SQL_INTEGER is "long".

It's foramtive as you taught me about SQLINTEGER in SQL/CLI.
Microsoft gave an example which can be used in their working
16-bit OSs and comimg 32-bit OSs.

Please note that at that time neither SQL/CLI nor ODBC guaranteed
that the spec would be valid under 64-bit paltforms.
It was not so long ago the spec of 64-bit ODBC was determined.

>> Though you emphasize ODBC is a superset, ODBC was not a superset
>> of sql/cli from the first. In the first place SQL/CLI didn't exist
>> when ODBC was introduced. Of cource SQL_C_XXXX was not an extension
>> of sql/cli spec then. You can't find SQL_C_XXXX because SQL_C_XXXX
>> is a C-specific concept and maybe sql/cli shrinked the spec so as
>> to avoid language-specific concept. As a result the spec uses the
>> same notations SQL_xxxx for different kind of concepts. ODBC uses
>> different notations for different kind of concepts.
>
> Yeah.
>
>> Which do you prefer?
>
> I would recommend applications to not use SQL_C_xxx type codes. I would
> recommend using a SQLINTEGER variable with SQL_INTEGER type code. That's
> the most readable, and most portable option.

> (I actually like the idea of separate SQL_C_xxx type codes, to refer to
> the native types.

Unfortunately such a use is inappropriate in database programing.
For example I can find the following in SQL/CLI spec.

2.2.2 Data type for C
   For binary compatibility of object modules, applications must use
   symbolic data types defined ...

It's very important and you are saying the opposite of SQL/CLI
recommendation from the first.
What you have to discuss with is the Open Group not unixODBC.

>> Now I'm examining what SQLINTEGER means in SQL/CLI spec though
>> it may be an old one.
>> Hmmm, could you please tell me SQLINTEGER is a 32-bit integer,
>> 64-bit one or platform-dependent one on 64-bit platforms?
>> I find a line
>>     SQLINTEGER long  Length of buffers for column data and ...
>> Is it right in the latest spec?
>
> Hmm, I don't see that line in my copy. But it does include a sample
> sqlcli.h header file that has this in Annex H:
>
> typedef long SQLINTEGER;
> typedef long long SQLBIGINT;
>
> That probably assumes that "long" is 32-bits wide.

It's very important whether SQLINTEGER means 32-bit or 64-bit
in 64-bit platforms. If SQLINTEGER means 64-bit integers in
SQL/CLI, I have to tell members of this list not to use it.

> The Annex has been
> marked as "informative", so it's only meant as an example, though.

Yes it's formative. And so is for ODBC. As you emphasized many times
ODBC became a superset of SQL/CLI conseqently.

regards,
Hiroshi Inoue