Re: New libpq based driver snapshot 08.01.0003 available
От | Zoltan Boszormenyi |
---|---|
Тема | Re: New libpq based driver snapshot 08.01.0003 available |
Дата | |
Msg-id | 42F1081C.6020509@dunaweb.hu обсуждение исходный текст |
Ответ на | New libpq based driver snapshot 08.01.0003 available ("Dave Page" <dpage@vale-housing.co.uk>) |
Ответы |
Re: New libpq based driver snapshot 08.01.0003 available
|
Список | 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 по дате отправления:
Следующее
От: Zoltan BoszormenyiДата:
Сообщение: Re: New libpq based driver snapshot 08.01.0003 available