Re: New libpq based driver snapshot 08.01.0003 available

From: Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: New libpq based driver snapshot 08.01.0003 available
Date: 2005-08-03 18:08:28
Message-ID: 42F1081C.6020509@dunaweb.hu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 website within 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. This is 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 transactional mode, and completely broke Use Declare/Fetch mode.
>
> Please take some time to test this driver and report any bugs to pgsql-odbc(at)postgresql(dot)org(dot)
>
> 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:287 and 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, and doesn'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

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Zoltan Boszormenyi 2005-08-03 19:34:13 Re: New libpq based driver snapshot 08.01.0003 available
Previous Message Laura Vance 2005-08-03 15:57:28 iODBC vs unixODBC (which to use)