Re: New libpq based driver snapshot 08.01.0003 available - Mailing list pgsql-odbc

From Zoltan Boszormenyi
Subject Re: New libpq based driver snapshot 08.01.0003 available
Date
Msg-id 42F1081C.6020509@dunaweb.hu
Whole thread Raw
In response to New libpq based driver snapshot 08.01.0003 available  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: New libpq based driver snapshot 08.01.0003 available  (Zoltan Boszormenyi <zboszor@dunaweb.hu>)
List pgsql-odbc
Dave Page írta:
> I've uploaded a new snapshot of the libpq based version of psqlODBC to
ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/.It will propagate onto the mirrors and the file listing on the
websitewithin the next day or so. 
>
> Important changes in this release include:
>
> - SSL support
>
> - Fixed a nasty SQLGetData/SQL_C_WCHAR bug that basically completely broke piecemeal retrieval of Unicode strings.
Thisis believed to be /the/ bug that stopped many users using versions newer than 07.03.0200. 
>
> - Fixed a bug new to the libpq version of the driver that prevented ODBCbench running properly in multithread
transactionalmode, and completely broke Use Declare/Fetch mode. 
>
> Please take some time to test this driver and report any bugs to pgsql-odbc@postgresql.org.
>
> Regards, Dave.
>
>
> Change list
> -----------
>
> - Added SSL support
> - Fix some errors found by static source analysis (using Klocwork). [Tomas Skäre]
> - In SC_pos_reload_needed:2189 rows_per_fetch is uninitialised, if create_from_scratch is false, per Tomas Skäre
> - In SQLGetDescFieldW:128 blen is not initialised before sent to utf8_to_ucs2(). The same thing exists in
SQLColAttributeW:287and SQLGetDiagFieldW:345, per Tomas Skäre 
> - Get proper error messages from the server, rather than just saying the database doesn't exist.
> - Japanese GUI update from Hiroshi Saito
> - Include win_unicode.c in Unix build because it contains functions that are used under unix.
> - Fix SQL_MAX_IDENTIFIER_LEN per gborg bug ref: 1348
> - Fix memory leak per gborg bug 1356 [pauldaugherty]
> - Fix unicode copy & convert bug. SQLGetData with SQL_C_WCHAR now returns SQL_SUCCESS once the whole string is sent,
anddoesn't lose odd characters like it did. 
> - Fix bug that stopped Use Declare/Fetch working, and prevented ODBC bench running in multi-thread, multi-transaction
mode.
> - Add comment about a known leak bug that needs fixing
> - Handle SQL_DATE from ODBC2 apps, per bug report 1292 [    alic <NOSPAM> sokrates.hr]
> - Fix per bug ref 1187 [Scot Loach]

I got these on compiling the latest CVS
using the RedHat RawHide src.rpm environment:

...
options.c: In function `PGAPI_SetConnectOption':
options.c:500: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
...
odbcapi30.c: In function `SQLSetEnvAttr':
odbcapi30.c:433: warning: cast from pointer to integer of different size
odbcapi30.c:454: warning: cast from pointer to integer of different size
odbcapi30.c:461: warning: cast from pointer to integer of different size
...
pgapi30.c: In function `ARDSetField':
pgapi30.c:455: warning: cast from pointer to integer of different size
pgapi30.c:464: warning: cast from pointer to integer of different size
pgapi30.c:467: warning: cast from pointer to integer of different size
pgapi30.c:512: warning: cast from pointer to integer of different size
pgapi30.c:521: warning: cast from pointer to integer of different size
pgapi30.c:537: warning: cast from pointer to integer of different size
pgapi30.c:554: warning: cast from pointer to integer of different size
pgapi30.c:557: warning: cast from pointer to integer of different size
pgapi30.c:560: warning: cast from pointer to integer of different size
pgapi30.c: In function `APDSetField':
pgapi30.c:630: warning: cast from pointer to integer of different size
pgapi30.c:639: warning: cast from pointer to integer of different size
pgapi30.c:642: warning: cast from pointer to integer of different size
pgapi30.c:662: warning: cast from pointer to integer of different size
pgapi30.c:671: warning: cast from pointer to integer of different size
pgapi30.c:687: warning: cast from pointer to integer of different size
pgapi30.c:700: warning: cast from pointer to integer of different size
pgapi30.c:706: warning: cast from pointer to integer of different size
pgapi30.c:709: warning: cast from pointer to integer of different size
pgapi30.c: In function `IPDSetField':
pgapi30.c:795: warning: cast from pointer to integer of different size
pgapi30.c:803: warning: cast from pointer to integer of different size
pgapi30.c:822: warning: cast from pointer to integer of different size
pgapi30.c:831: warning: cast from pointer to integer of different size
pgapi30.c:847: warning: cast from pointer to integer of different size
pgapi30.c:850: warning: cast from pointer to integer of different size
pgapi30.c:853: warning: cast from pointer to integer of different size
pgapi30.c: In function `PGAPI_SetConnectAttr':
pgapi30.c:1526: warning: cast from pointer to integer of different size
pgapi30.c:1536: warning: cast from pointer to integer of different size
pgapi30.c: In function `PGAPI_SetStmtAttr':
pgapi30.c:1674: warning: cast from pointer to integer of different size
pgapi30.c:1703: warning: cast from pointer to integer of different size
pgapi30.c:1715: warning: cast from pointer to integer of different size
pgapi30.c:1730: warning: cast from pointer to integer of different size
pgapi30.c:1733: warning: cast from pointer to integer of different size
...

You guessed right, 64 bit system, FC3/x86-64.
Should I worry about these?

I reported it before for 8.00.x and late 7.x.y ODBC versions
and I thought I give it a try again. This statement:

select jk.id,jk.datum,megrend.nev,well.nev,csoport.nev,jk.muszak
from jk left outer join csoport on (csoport.id=jk.csoport),
megrend,well where jk.megr=megrend.id and jk.fpont=well.id;

fails. The application gets the first row, but SQLFetch() returns error
for the second. The other variant of the same statement also fails.

select jk.id,jk.datum,megrend.nev,well.nev,
   (select nev from csoport where id=jk.csoport),
   jk.muszak from jk,megrend,well where jk.megr=megrend.id and
jk.fpont=well.id;

Simplifying the query by omitting the OUTER JOIN
does not make it work. :-(

select jk.id,jk.datum,megrend.nev,well.nev,jk.muszak from
jk,megrend,well where jk.megr=megrend.id and jk.fpont=well.id;

Uh-oh. Omitting all the fields that may have NULL values fixes it.
Incidentally, the second row already contained NULL fields.

So the problem isn't with complex queries but with NULL values.

I used NULL as the last parameter of SQLBindCol() for every fields
meaning I don't care to be notified about NULL values.

Last thing I tried was to use 3 SQLINTEGER for the 3 fields that may
have NULL values and use &null_val1, etc. as the last parameter
for SQLBindCol(). And it finally fixed it, I get all the rows that
e.g. psql produce for the same query.

I looked quickly at the sources and copy_and_convert_field() in
convert.c has this at line 481:

-----------------------------------------------
         if (!value)
         {
                 /*
                  * handle a null just by returning SQL_NULL_DATA in
pcbValue, and
                  * doing nothing to the buffer.
                  */
                 if (pcbValue)
                 {
                         *((SDWORD *) pcbValueBindRow) = SQL_NULL_DATA;
                         return COPY_OK;
                 }
                 else
                 {
                         SC_set_error(stmt,
STMT_RETURN_NULL_WITHOUT_INDICATOR, "StrLen_or_IndPtr was a null pointer
and NULL data was retrieved");
                         SC_log_error(func, "", stmt);
                         return  SQL_ERROR;
                 }
         }
-----------------------------------------------

unixODBC-2.2.5 sources contains copyies of two very old
ODBC drivers, newer one (reports version 07.01.0003) has this
in copy_and_convert_field() in convert.c, line 228:

-----------------------------------------------
         if ( ! value) {
         /* handle a null just by returning SQL_NULL_DATA in pcbValue, */
         /* and doing nothing to the buffer.                           */
         if(pcbValue) {
                         *(SDWORD *) ((char *) pcbValue +
pcbValueOffset) = SQL_NULL_DATA;
         }
                 free(tempBuf);
                 return COPY_OK;
         }
-----------------------------------------------

The old version returns COPY_OK for both cases, although the logging
in the new version is nice. Which is the correct behaviour? I would like
to be able to ignore NULL notification.

Best regards,
Zoltán Böszörményi

pgsql-odbc by date:

Previous
From: Laura Vance
Date:
Subject: iODBC vs unixODBC (which to use)
Next
From: Zoltan Boszormenyi
Date:
Subject: Re: New libpq based driver snapshot 08.01.0003 available