Release plan
am 27.03.2009 15:19:25 von Hiroshi Saito
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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: Release plan
am 27.03.2009 16:55:50 von Dave Page
On Fri, Mar 27, 2009 at 2:19 PM, Hiroshi Saito 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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: Release plan
am 27.03.2009 17:28:13 von Hiroshi Saito
Hi.
----- Original Message -----
From: "Dave Page"
>> 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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: Release plan
am 27.03.2009 18:32:17 von devrim
--=-XhBowev8OfpbzMuoRNzR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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.
--=20
Devrim GÃNDÃZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
--=-XhBowev8OfpbzMuoRNzR
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAknNDaAACgkQtl86P3SPfQ6IqgCglHVbHXADzTAanjht58MH ulmE
55UAoKQ2FvMHQ1jP/SaUgjxeoJgFOYAo
=CjP3
-----END PGP SIGNATURE-----
--=-XhBowev8OfpbzMuoRNzR--
Re: Release plan
am 27.03.2009 18:38:49 von Hiroshi Saito
Hi Devrim-san.
----- Original Message -----=20
From: "Devrim GÃNDÃZ"
>> 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=20
--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: [Q] specifying bigint
am 28.03.2009 04:14:31 von V S P
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
SWORD -25
SWORD -5
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
SWORD -25
SWORD -5
SQLULEN 8
SWORD 0
PTR 0x00907D78
SQLLEN 8
SQLLEN * 0x00907D68 (8)
prb_bigint d98-110 ENTER SQLBindParameter
HSTMT 00921C28
UWORD 2
SWORD 1
SWORD 1
SWORD 12
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
SWORD 1
SWORD 12
SQLULEN 31
SWORD 0
PTR 0x00907E00
SQLLEN 32
SQLLEN * 0x00907980 (-3)
prb_bigint d98-110 ENTER SQLBindParameter
HSTMT 00921C28
UWORD 3
SWORD 1
SWORD -25
SWORD -5
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
SWORD -25
SWORD -5
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
SQLHANDLE 00921C28
prb_bigint d98-110 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 3
SQLHANDLE 00921C28
prb_bigint d98-110 ENTER SQLEndTran
SQLSMALLINT 2
SQLHANDLE 009215E8
SQLSMALLINT 0
prb_bigint d98-110 EXIT SQLEndTran with return code 0
(SQL_SUCCESS)
SQLSMALLINT 2
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
SQLHANDLE 009215E8
prb_bigint d98-110 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 2
SQLHANDLE 009215E8
prb_bigint d98-110 ENTER SQLFreeHandle
SQLSMALLINT 1
SQLHANDLE 00921540
prb_bigint d98-110 EXIT SQLFreeHandle with return code 0
(SQL_SUCCESS)
SQLSMALLINT 1
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.
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: [Q] specifying bigint
am 28.03.2009 12:26:05 von Hiroshi Inoue
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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: Release plan
am 28.03.2009 15:04:34 von Johann Zuschlag
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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: [Q] specifying bigint
am 29.03.2009 04:32:38 von V S P
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"
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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: Release plan
am 29.03.2009 15:28:58 von Hiroshi Saito
Hi.
From: "Johann Zuschlag"
> 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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: [Q] specifying bigint
am 29.03.2009 23:23:44 von V S P
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.manife st"
/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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: [Q] specifying bigint
am 30.03.2009 05:15:28 von Hiroshi Inoue
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
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc