Thread: Release plan
Hi. We equipped some problem corrections and the new feature from 08.03.0400. Then, sslverify is in one of the new features. It serves as libpq of Version8.4. However, Compile and operation are possible satisfactory as libpq of Version8.3. Then, two choices can be considered. 1. Releases including libpq of Version 8.3 as a stable version of 08.03.0500. 2. Release 08.04.0100 in accordance with the release of libpq of Version 8.4. I think decide by vote. or some idea? Changes: 1.) Avoid a crash on exit when using SSL connections by resetting CRTPTO_xx_callbacks before unloding libpq. 2.) Correct the funtion name DiscardRollbackState pointed out by Zoltan Boszormenyi. 3.) Correct the value of INDEX_QUALIFIER column which returned by SLQSTATISTICS(); 4.) Take domain types into account in SQLColumns() (Thanks to Luiz K. Matsumura). 5.) Take RESTRICT actions into account in SQLForeignKeys() (report from Farid Zidan). 6.) Fix a bug that small negative decimal values are mistaken for non-negative (bug report from Dominic Smith). 7.) Use MSG_NOSIGNAL/MSG_NOSIGPIPE option on send()/recv() to avoid crash on SIGPIPE (bug report from Brian Feldman). 8.) Remove a spurious "." with no trailing digits in timestamp representation (bug report from Brian Feldman). 9.) Rename trim() funtion in order to avoid conflict of function name(report from Dominic Smith). 10.) Put back the change to add *read only* clause for read only cursors. 11.) Improve pgtype_transfer_octet_length(). 12.) Fix a bug reported by Milen Manev that SQLExec *select for a table* -> SQLDescribeCol() -> add a column to the table -> SQLExec *select for the table* -> SQLDescribeCol() for the added column causes a bad result. 13.) Use strncpy_null() instead of strncpy(). 14.) Close (holdable) cursors on commit if possible. 15.) Recycle columns cache info if the size becomes pretty large. 16.) Add sslverify=none to conninfo in case of SSL connections via libpq of version 8.4. 17.) Add a functionality to change the directory for logging. 18.) Correct the error code for communication errors. 19.) Correct the conversion between UTF-16 and UTF-8 for non UCS2 characters. 20.) Try to convert (especially connection error) messages using local conversions when they are not valid unicode characters. 21.) Add a textbox to setup dialog to change the directory for logging. Regards, Hiroshi Saito
On Fri, Mar 27, 2009 at 2:19 PM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: > Hi. > > We equipped some problem corrections and the new feature from 08.03.0400. > Then, sslverify is in one of the new features. It serves as libpq of > Version8.4. > However, Compile and operation are possible satisfactory as libpq of > Version8.3. > Then, two choices can be considered. > > 1. Releases including libpq of Version 8.3 as a stable version of > 08.03.0500. > 2. Release 08.04.0100 in accordance with the release of libpq of Version > 8.4. If there are 8.4 features in the driver, then surely it should be 08.04.0100? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Hi. ----- Original Message ----- From: "Dave Page" <dpage@pgadmin.org> >> 1. Releases including libpq of Version 8.3 as a stable version of >> 08.03.0500. >> 2. Release 08.04.0100 in accordance with the release of libpq of Version >> 8.4. > > If there are 8.4 features in the driver, then surely it should be 08.04.0100? Ah, Ok. We are likely to have time to run check test of further some. in the hopefully, After the release of pg8.4. Regards, Hiroshi Saito
On Fri, 2009-03-27 at 15:55 +0000, Dave Page wrote:
> If there are 8.4 features in the driver, then surely it should be
> 08.04.0100?
+1.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
Attachment
Hi Devrim-san. ----- Original Message ----- From: "Devrim GÜNDÜZ" <devrim@gunduz.org> >> If there are 8.4 features in the driver, then surely it should be >> 08.04.0100? > > +1. Yeah:-) P.S) As for build, even Version 8.3 and 8.4 is our psqlODBC is possible.! Regards, Hiroshi Saito
HI,
I did some more tracing, and it looks like the data is sent to ODBC
correctly (bigint, char, bigint)
and it is somewhere within ODBC driver or after, bigints are converted
to strings
Wanted to ask if there is may be a workaround of some sort to keep
bigints
as number not strings
here is the ODBC trace of the offending update (Ascii driver on windows)
the bigint appear to be 'announced' as bigints
(prb_bigint is my program name)
The error indicates, however that somewhere bigint is converted to a
string
in 'f3=t.f3"
DIAG [42883] ERROR: operator does not exist: bigint = text;
Error while executing the query (7)
------------------------
prb_bigint d98-110 ENTER SQLPrepare
HSTMT 00921C28
UCHAR * 0x009078F0 [ -3] "UPDATE test_tab SET f2= t.f2,f3=t.f3 from(VALUES( ? , ?
, ? ))as t(f1,f2,f3) WHERE test_tab.f1=t.f1\ 0"
SDWORD -3
prb_bigint d98-110 EXIT SQLPrepare with return code 0
(SQL_SUCCESS)
HSTMT 00921C28
UCHAR * 0x009078F0 [ -3] "UPDATE test_tab SET f2= t.f2,f3=t.f3 from(VALUES( ? , ?
, ? ))as t(f1,f2,f3) WHERE test_tab.f1=t.f1\ 0"
SDWORD -3
prb_bigint d98-110 ENTER SQLBindParameter
HSTMT 00921C28
UWORD 1
SWORD 1 <SQL_PARAM_INPUT>
SWORD -25 <SQL_C_SBIGINT>
SWORD -5 <SQL_BIGINT>
SQLULEN 8
SWORD 0
PTR 0x00907D78
SQLLEN 8
SQLLEN * 0x00907D68
prb_bigint d98-110 EXIT SQLBindParameter with return code 0
(SQL_SUCCESS)
HSTMT 00921C28
UWORD 1
SWORD 1 <SQL_PARAM_INPUT>
SWORD -25 <SQL_C_SBIGINT>
SWORD -5 <SQL_BIGINT>
SQLULEN 8
SWORD 0
PTR 0x00907D78
SQLLEN 8
SQLLEN * 0x00907D68 (8)
prb_bigint d98-110 ENTER SQLBindParameter
HSTMT 00921C28
UWORD 2
SWORD 1 <SQL_PARAM_INPUT>
SWORD 1 <SQL_C_CHAR>
SWORD 12 <SQL_VARCHAR>
SQLULEN 31
SWORD 0
PTR 0x00907E00
SQLLEN 32
SQLLEN * 0x00907980
prb_bigint d98-110 EXIT SQLBindParameter with return code 0
(SQL_SUCCESS)
HSTMT 00921C28
UWORD 2
SWORD 1 <SQL_PARAM_INPUT>
SWORD 1 <SQL_C_CHAR>
SWORD 12 <SQL_VARCHAR>
SQLULEN 31
SWORD 0
PTR 0x00907E00
SQLLEN 32
SQLLEN * 0x00907980 (-3)
prb_bigint d98-110 ENTER SQLBindParameter
HSTMT 00921C28
UWORD 3
SWORD 1 <SQL_PARAM_INPUT>
SWORD -25 <SQL_C_SBIGINT>
SWORD -5 <SQL_BIGINT>
SQLULEN 8
SWORD 0
PTR 0x00907A08
SQLLEN 8
SQLLEN * 0x00907A18
prb_bigint d98-110 EXIT SQLBindParameter with return code 0
(SQL_SUCCESS)
HSTMT 00921C28
UWORD 3
SWORD 1 <SQL_PARAM_INPUT>
SWORD -25 <SQL_C_SBIGINT>
SWORD -5 <SQL_BIGINT>
SQLULEN 8
SWORD 0
PTR 0x00907A08
SQLLEN 8
SQLLEN * 0x00907A18 (8)
prb_bigint d98-110 ENTER SQLExecute
HSTMT 00921C28
prb_bigint d98-110 EXIT SQLExecute with return code -1
(SQL_ERROR)
HSTMT 00921C28
DIAG [42883] ERROR: operator does not exist: bigint = text;
Error while executing the query (7)
prb_bigint d98-110 ENTER SQLGetDiagRecW
SQLSMALLINT 3
SQLHANDLE 00921C28
SQLSMALLINT 1
SQLWCHAR * 0x00128420 (NYI)
SQLINTEGER * 0x00128D18
SQLWCHAR * 0x00922358 (NYI)
SQLSMALLINT 511
SQLSMALLINT * 0x001284A8
prb_bigint d98-110 EXIT SQLGetDiagRecW with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3
SQLHANDLE 00921C28
SQLSMALLINT 1
SQLWCHAR * 0x00128420 (NYI)
SQLINTEGER * 0x00128D18 (7)
SQLWCHAR * 0x00922358 (NYI)
SQLSMALLINT 511
SQLSMALLINT * 0x001284A8 (78)
prb_bigint d98-110 ENTER SQLFreeHandle
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 00921C28
prb_bigint d98-110 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3 <SQL_HANDLE_STMT>
SQLHANDLE 00921C28
prb_bigint d98-110 ENTER SQLEndTran
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 009215E8
SQLSMALLINT 0
prb_bigint d98-110 EXIT SQLEndTran with return code 0
(SQL_SUCCESS)
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 009215E8
SQLSMALLINT 0
prb_bigint d98-110 ENTER SQLDisconnect
HDBC 009215E8
prb_bigint d98-110 EXIT SQLDisconnect with return code 0
(SQL_SUCCESS)
HDBC 009215E8
prb_bigint d98-110 ENTER SQLFreeHandle
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 009215E8
prb_bigint d98-110 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 2 <SQL_HANDLE_DBC>
SQLHANDLE 009215E8
prb_bigint d98-110 ENTER SQLFreeHandle
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00921540
prb_bigint d98-110 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 1 <SQL_HANDLE_ENV>
SQLHANDLE 00921540
--------------------------
On Fri, 27 Mar 2009 16:20 -0400, pgsql-odbc@postgresql.org wrote:
> Hello,
> wanted to ask what is the apropriate way to specify
> bind variables for 'bigint' columns
>
>
> I am using OTL library to abstract ODBC details out
> and in there
>
> every bigint is converted to
> 'string version' of long long
>
> This makes the following SQL statement invalid
>
>
>
>
> UPDATE test_tab SET f2= t.f2,f3=t.f3 from(VALUES( '10'
> , 'Name changed' , '9999' ))as
> t(f1::bigint,f2,f3::bigint)
> WHERE test_tab.f1=t.f1
>
>
> ----------
> test_tab declared as f1 bigint, f2 char(31), f3 bigint.
>
>
>
> The error is in "f3=t.f3"
>
> because Postgres assumes that the t.f3 is of type string -- probably
> because
> the '9999' is string at it automatically derives the type.
>
> So I am thinking that I either must tell postgres, that
> t.t3 is also bigint
>
> or do f3=t.f3::bigint
>
>
> However, adding the bigint typecast is actually difficult for me now,
> because I created an ActiveRecord-like framework for C++ (where C++
> variables
> contain enough information to be used as 'Fields' that belong to
> 'database-aware'
> Active record)
>
>
> so handling an exception like this for bigints is difficult.
>
>
> So I wanted to find out
> a) is it necessary in Pg odbc on windows and Unix to use strings to
> pass data in and to read in for bigints?
> Is there may be another way (they are 'long long' c++ data types)
>
> b) is there another way (I am using this type of update to do 'bulk'
> update
> of several rows at the same time
>
>
>
> thank you in advance,
> Vlad
>
>
>
> --
> V S P
> toreason@fastmail.fm
>
> --
> http://www.fastmail.fm - One of many happy users:
> http://www.fastmail.fm/docs/quotes.html
>
--
V S P
toreason@fastmail.fm
--
http://www.fastmail.fm - A fast, anti-spam email service.
V S P wrote:
> HI,
> I did some more tracing, and it looks like the data is sent to ODBC
> correctly (bigint, char, bigint)
> and it is somewhere within ODBC driver or after, bigints are converted
> to strings
> Wanted to ask if there is may be a workaround of some sort to keep
> bigints
> as number not strings
>
>
> here is the ODBC trace of the offending update (Ascii driver on windows)
> the bigint appear to be 'announced' as bigints
> (prb_bigint is my program name)
>
> The error indicates, however that somewhere bigint is converted to a
> string
> in 'f3=t.f3"
>
> DIAG [42883] ERROR: operator does not exist: bigint = text;
> Error while executing the query (7)
>
>
> ------------------------
> prb_bigint d98-110 ENTER SQLPrepare
> HSTMT 00921C28
> UCHAR * 0x009078F0 [ -3] "UPDATE test_tab SET f2= t.f2,f3=t.f3 from(VALUES( ? , ?
, ? ))as t(f1,f2,f3) WHERE test_tab.f1=t.f1\ 0"
> SDWORD -3
How about
UPDATE test_tab SET f2=t.f2, f3=t.f3 from (VALUES (?::bigint, ?,
?::bigint)) as t(f1,f2,f3) WHERE test_tab.f1=t.f1
?
regards,
Hiroshi Inoue
Hi Hiroshi, > 2. Release 08.04.0100 in accordance with the release of libpq of > Version 8.4. > I vote for number 2. regards, Johann Zuschlag
Hi,
thank you
that worked
I kind of do not understand still why there is a conversion
to string -- is this 'expected behavior'
(so that at least I would know in the future it applies to somewhere
else)
Also wanted to ask
is SQLRowCount() function working for
updates and inserts?
thank you in advance,
Vlad
On Sat, 28 Mar 2009 20:26 +0900, "Hiroshi Inoue" <inoue@tpf.co.jp>
wrote:
> V S P wrote:
> > HI,
> > I did some more tracing, and it looks like the data is sent to ODBC
> > correctly (bigint, char, bigint)
> > and it is somewhere within ODBC driver or after, bigints are converted
> > to strings
> > Wanted to ask if there is may be a workaround of some sort to keep
> > bigints
> > as number not strings
> >
> >
> > here is the ODBC trace of the offending update (Ascii driver on windows)
> > the bigint appear to be 'announced' as bigints
> > (prb_bigint is my program name)
> >
> > The error indicates, however that somewhere bigint is converted to a
> > string
> > in 'f3=t.f3"
> >
> > DIAG [42883] ERROR: operator does not exist: bigint = text;
> > Error while executing the query (7)
> >
> >
> > ------------------------
> > prb_bigint d98-110 ENTER SQLPrepare
> > HSTMT 00921C28
> > UCHAR * 0x009078F0 [ -3] "UPDATE test_tab SET f2= t.f2,f3=t.f3 from(VALUES( ? , ?
, ? ))as t(f1,f2,f3) WHERE test_tab.f1=t.f1\ 0"
> > SDWORD -3
>
> How about
> UPDATE test_tab SET f2=t.f2, f3=t.f3 from (VALUES (?::bigint, ?,
> ?::bigint)) as t(f1,f2,f3) WHERE test_tab.f1=t.f1
> ?
>
> regards,
> Hiroshi Inoue
--
V S P
toreason@fastmail.fm
--
http://www.fastmail.fm - IMAP accessible web-mail
Hi. From: "Johann Zuschlag" <zuschlag2@online.de> > Hi Hiroshi, > >> 2. Release 08.04.0100 in accordance with the release of libpq of >> Version 8.4. >> > I vote for number 2. Yeah, It will be pleased with all help by the reason for having sufficient test time. we are hopefully. Regards, Hiroshi Saito
Hi, When trying to build ODBC (_08_03_0400) on windows using VC 2008 compiler I am getting link errors (compilation was ok with just type missmatch warnings) ------ Build started: Project: psqlODBC, Configuration: Release Win32 ------ Linking... Creating library psqlodbc35w.lib and object psqlodbc35w.exp LINK : warning LNK4199: /DELAYLOAD:libeay32.dll ignored; no imports found from libeay32.dll LINK : warning LNK4199: /DELAYLOAD:XOLEHLP.DLL ignored; no imports found from XOLEHLP.DLL socket.obj : error LNK2001: unresolved external symbol _getaddrinfo@16 socket.obj : error LNK2001: unresolved external symbol _freeaddrinfo@4 socket.obj : error LNK2019: unresolved external symbol __imp__getnameinfo@28 referenced in function _SOCK_connect_to psqlodbc35w.dll : fatal error LNK1120: 3 unresolved externals Build log was saved at "file://c:\temp\pgODBCsrc\Release\BuildLog.htm" psqlODBC - 4 error(s), 2 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== ------------------------------------ what is missing in the link line? I have /OUT:"psqlodbc35w.dll" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files\PostgreSQL\8.3\lib" /LIBPATH:"C:\usr\local\openssl-rel\lib" /DLL /MANIFEST /MANIFESTFILE:".\Release\psqlodbc35w.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEF:".\psqlodbc.def" /DELAYLOAD:"libpq.dll" /DELAYLOAD:"ssleay32.dll" /DELAYLOAD:"libeay32.dll" /DELAYLOAD:"secur32.dll" /DELAYLOAD:"crypt32.dll" /DELAYLOAD:"XOLEHLP.DLL" /PDB:"psqlodbc35w.pdb" /SUBSYSTEM:WINDOWS /DYNAMICBASE:NO /IMPLIB:"psqlodbc35w.lib" /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib XOleHlp.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib wsock32.lib winmm.lib libpq.lib ssleay32.lib libeay32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib DelayImp.lib I am using the supplied proj file, and wsock32 is included. ---------- thanks, Vlad -- V S P toreason@fastmail.fm -- http://www.fastmail.fm - Access your email from home and the web
V S P wrote: > Hi, > thank you > that worked > > > I kind of do not understand still why there is a conversion > to string -- is this 'expected behavior' > (so that at least I would know in the future it applies to somewhere > else) Fundamentally the driver handles parameters as unknown type and leave the conversion to the backend. > Also wanted to ask > > is SQLRowCount() function working for > updates and inserts? Yes. regards, Hiroshi Inoue