Michael Paquier | 29 Jan 05:27 2015
Picon

Build broken since 9aaa062 because of missing isnan and isinf

Hi,

As mentioned in $subject, build of regression tests is broken on
Windows as follows:
.\src\common.obj
result-conversions-test.obj : error LNK2019: unresolved external
symbol isinf referenced in function printdouble
result-conversions-test.obj : error LNK2019: unresolved external
symbol isnan referenced in function printdouble
.\src\result-conversions-test.exe : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\Bin\amd64\cl.EXE"' : return code '0x2'
Stop.
I think that we are going to need something like the patch attached to
define explicitly isnan and isinf.
Regards,
-- 
Michael

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Heikki Linnakangas | 28 Jan 12:42 2015

Regression tests

Hi,

Last weekend I tried to run the regression tests on a different system 
than what I usually use, but it failed because the system didn't have 
pg_regress installed. It had a PostgreSQL server running, and it had 
libpq and libpq header files, but pg_regress and the rest of the PGXS 
system was not included in those OS packages.

It was easy enough to install the right packages (apt-get install ...), 
but it's nevertheless a bit silly that we depend on PGXS and pg_regress. 
When I wrote the regression suite, I actually had to jump through some 
hoops to use pg_regress in the first place. There's the ugly hack where 
"make installcheck" creates the .sql files that just run the test binaries.

Using pg_regress also means that the ODBC.ini file must agree with the 
current PGHOST etc. settings. Otherwise psql will fail to connect even 
if odbc.ini is correct, or worse, it will connect to a different server.

I've also been trying to make it easier to run the regression tests on 
Windows. Using psql and pg_regress is a bit of pain there, and again it 
requires that you have those installed on the build machine, which isn't 
a given.

For these reasons, I propose to refactor the way the regression tests 
are launched. I wrote a small C utility to basically replace pg_regress. 
It runs the test programs, compares their outputs with the expected 
outputs, and runs "diff" to create regression.diffs file if they don't 
match. It produces TAP-compatible output, which is nice because you can 
use a frontend like perl 'prove' program to pretty-print it with colors 
and everything, and you can easily integrate it with tools like Jenkins. 
(Continue reading)

Heikki Linnakangas | 26 Jan 09:36 2015

Let's get rid of premature execution

Hi,

Under some circumstances, the driver currently does so-called "premature 
execution". This means that when the application does something like this:

SQLPrepare("SELECT function()");
SQLNumResultCols();

but does not run SQLExecute(), the driver executes the statement anyway. 
This is documented, and there's an option to disable this 
(DisallowPremature=1), and it only happens with UseServerSidePrepare=0,
and only with statements starting with SELECT, but IMHO it's 
nevertheless scary as hell.

Currently, with DisallowPremature=1, the driver simply does not return 
any information for calls like SQLNumResultCols() that are called before 
SQLExecute().

I propose changes to this:

1. The driver should never do premature execution. That's just evil. 
Remove DisallowPremature option.

2. When SQLNumResultCols() is called before SQLExecute(), the driver 
will parse and describe the query in the server, even if 
UseServerSidePrepare=0. This does not affect how the query will be 
executed later. In the query that is sent to the server, the parameter 
markers are replaced with NULLs, similar to how they are replaced with 
the real values later when the query is executed. (This code exists 
already; we did the same thing in DisallowPremature mode when we sent 
(Continue reading)

Heikki Linnakangas | 26 Jan 08:07 2015

Coverity and Clang Static Analyzer runs

I registered psqlodbc for the Coverity Scan program at 
scan.coverity.org, and performed the initial run. I fixed a bunch of 
issues that it pointed out.

I also ran Clang Static Analyzer, which pointed out some of the same 
issues as Coverity did, and a few others. I've fixed a bunch of those too.

If you'd like to help out weeding the Coverity defects, sign up at 
scan.coverity.org. A few dozen defects remain, most of which seem to be 
false positives at a quick glance. For now, I plan to run it manually on 
my laptop every now and then.

- Heikki

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

psqlodbc-bugs | 22 Jan 08:23 2015

[psqlodbc-Bugs][1000790] String data field with only 1 letter length

psqlodbc-Bugs item #1000790, was changed at 2015-01-22 09:23 by Heikki Linnakangas
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1000790&group_id=1000125
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here, only in plain text format)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

>Status: Closed
Priority: 3
Submitted By: Nobody (None)
Assigned to: Nobody (None)
Summary: String data field with only 1 letter length 
Category: None
Group: None
>Resolution: Out of Date
Category: None
Group: None
>Resolution: None


Initial Comment:
PostgreSQL 8.1.3
psqlODBC 8.02.02.00 Unicode

I use MFC (suppose to be 8.0 on VisualStudio 2005) CDatabase and CRecordset to retrieve data from a postgre database.
When the ODBC driver retrieve the data field type text that contain only 1 letter, CDBException is raised with return code is 100

If I make the data 2 characters or more then it's ok

(Continue reading)

psqlodbc-bugs | 22 Jan 14:02 2015

[psqlodbc-Bugs][1002767] Fatal exception error after running some queries

psqlodbc-Bugs item #1002767, was changed at 2015-01-22 13:02 by Andrus Moor
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1002767&group_id=1000125
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here, only in plain text format)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

Status: Closed
Priority: 3
Submitted By: Andrus Moor (kobruleht)
Assigned to: Nobody (None)
Summary: Fatal exception error after running some queries 
Category: None
Group: None
Resolution: Out of Date
Category: None
Group: None
Resolution: None

Initial Comment:
To reproduce:

Run some queries from Microsoft Visual FoxPro 9.0 SP1 against ODBC driver 
Log file containing queries and data is included.

Observed:

FoxPro crashes with access violation error.

(Continue reading)

psqlodbc-bugs | 22 Jan 08:24 2015

[psqlodbc-Bugs][1002767] Fatal exception error after running some queries

psqlodbc-Bugs item #1002767, was changed at 2015-01-22 09:24 by Heikki Linnakangas
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1002767&group_id=1000125
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here, only in plain text format)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

>Status: Closed
Priority: 3
Submitted By: Andrus Moor (kobruleht)
Assigned to: Nobody (None)
Summary: Fatal exception error after running some queries 
Category: None
Group: None
>Resolution: Out of Date
Category: None
Group: None
>Resolution: None

Initial Comment:
To reproduce:

Run some queries from Microsoft Visual FoxPro 9.0 SP1 against ODBC driver 
Log file containing queries and data is included.

Observed:

FoxPro crashes with access violation error.

(Continue reading)

psqlodbc-bugs | 22 Jan 07:52 2015

[psqlodbc-Bugs][1010834] QA Notice: Package has poor programming practices

psqlodbc-Bugs item #1010834, was changed at 2015-01-22 08:52 by Heikki Linnakangas
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010834&group_id=1000125
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here, only in plain text format)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

>Status: Closed
Priority: 3
Submitted By: Aaron Swenson (titanofold)
Assigned to: Nobody (None)
Summary: QA Notice: Package has poor programming practices 
Category: None
Group: None
Resolution: None
Category: None
Group: None
>Resolution: None

Initial Comment:
QA Notice: Package has poor programming practices which may compile fine but exhibit random runtime failures.

psqlodbc.c:55: warning: implicit declaration of function 'pthread_mutexattr_settype'

----------------------------------------------------------------------

>Comment By: Heikki Linnakangas (hlinnaka)
Date: 2015-01-22 08:52

(Continue reading)

psqlodbc-bugs | 22 Jan 07:44 2015

[psqlodbc-Bugs][1011265] psqlodbc driver won't connect when socket not in /tmp

psqlodbc-Bugs item #1011265, was changed at 2015-01-22 08:44 by Heikki Linnakangas
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011265&group_id=1000125
Or by replying to this e-mail entering your response between the following markers: 
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+
(enter your response here, only in plain text format)
#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+

Status: Open
Priority: 3
Submitted By: David Riedel (dpriedel)
Assigned to: Nobody (None)
Summary: psqlodbc driver won't connect when socket not in /tmp 
Category: None
Group: None
Resolution: None
Category: None
Group: None
Resolution: None

Initial Comment:
Arch Linux recenty updated their PostgreSQL to move the socket directory from /tmp to /run/postgresql. 
The database and psql both run fine.

However, psqlodbc can no longer connect to the database.

PostgreSQL version 9.2.1

psqlodbc version 09.01.0200

(Continue reading)

Heikki Linnakangas | 22 Jan 09:23 2015

Shutting down the pgfoundry project

Now that we have our website up at the new address, 
https://odbc.postgresql.org/ (Hooray!), let's shut down the web pages 
and project at PGFoundry.

Dave, Hiroshi I., Hiroshi S., you are the project admins at pgfoundry. 
Can you disable, or delete, or whatever you can do to the project there, 
please?

I don't think we care about remaining issues in the bug tracker. I 
briefly looked at a few of the latest ones, the remaining ones are many 
years old and probably not applicable anymore, or at least we have no 
plans to address them anyway.

It would be nice to put a 301 redirect from the pgfoundry site to the 
new site. We could try to ask Marc to set one up, but it's probably 
quicker to just drop an index.html with a meta-refresh tag there. I can 
do that, but is there some cron job that I need to disable, so that it 
doesn't get overwritten?

- Heikki

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Jens Wiechmann | 20 Jan 13:41 2015

09.03.0400, wrong real values

Hi,

I am using the database 9.4.0 with the odbc driver 09.03.0400  on linux machine with unixODBC.

 

There are different results if  I insert a float value=-0.0051 in the database with ODBC funtions SQLBindParameter(), SQLPrepare() and SQLExecute().

With the odbc version 09.03.0300 the saved value is 0.0051 and

with the odbc version 09.03.0400 the saved wrong value is -0.00510000018 (see below).

There is no difference between 32 and 64 bit.

 

Server Version on linux RHEL6:

psql (PostgreSQL) 9.4.0 (and 9.3.4 for the comparison)

 

 

~/.odbc.ini

[JWIE]

Driver=PostgreSQL

Port=5432

Database=jwie

FileUsage=1

UseServerSidePrepare=0

 

 

I use this table:

jwie=> \d TESTTABLE4;

                  Table "jwie.testtable4"

     Column      |            Type             | Modifiers

-----------------+-----------------------------+-----------

testtype        | character varying(64)       |

 testbooleanchar | character(1)                |

 testinteger     | bigint                      |

 testnumber      | numeric                     |

 testchar        | character(128)              |

 testvarchar     | character varying(128)      |

 testraw         | bytea                       |

 testlongraw     | bytea                       |

 testblob        | bytea                       |

 testlong        | text                        |

 testdate        | timestamp without time zone |

 testfloat       | double precision            |

 

 

C Code fragment:

:

   retcode = SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_CHAR, ID_LEN, 0, szTypeID, 0, &typeID);

   retcode = SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_C_FLOAT, SQL_FLOAT, sizeof(float), 0, &f2, 0, &charID);

   retcode = SQLBindParameter(hstmt, 3, SQL_PARAM_INPUT, SQL_C_FLOAT, SQL_FLOAT, sizeof(float), 0, &f3, 0, &numberID);

   retcode = SQLBindParameter(hstmt, 4, SQL_PARAM_INPUT, SQL_C_FLOAT, SQL_FLOAT, sizeof(float), 0, &f4, 0, &varcharID);

   retcode = SQLBindParameter(hstmt, 5, SQL_PARAM_INPUT, SQL_C_FLOAT, SQL_FLOAT, sizeof(float), 0, &f5, 0, &floatID);

 

   retcode = SQLPrepare(hstmt, (SQLCHAR*)"INSERT INTO TESTTABLE4 "

                                                    "(TESTTYPE, "

                                                    "TESTCHAR, "

                                                    "TESTNUMBER, "

                                                    "TESTVARCHAR, testfloat) "

                                                    "VALUES (?, ?, ?, ?, ?)", SQL_NTS);

 

   printf("retcode=%d\n", retcode);

   strcpy((char*)szTypeID, "FLOAT1");

   f2=-0.0051;

   f3=-0.0051;

   f4=-0.0051;

   f5=-0.0051;

   retcode = SQLExecute(hstmt);

:

 

Log files

 

09.03.0300 OK

========

conn = 0x198d2e0, PGAPI_Connect(DSN='JWIE', UID='jwie', PWD='xxxxx')

Driver Version='09.03.0300,201405140001'

Global Options: fetch=100, socket=4096, unknown_sizes=0, max_varchar_size=255, max_longvarchar_size=8190

                disable_optimizer=0, ksqo=1, unique_index=1, use_declarefetch=0

                text_as_longvarchar=1, unknowns_as_longvarchar=0, bools_as_char=1 NAMEDATALEN=64

                extra_systable_prefixes='dd_;', conn_settings='(null)' conn_encoding=''

    [ PostgreSQL version string = '9.3.4' ]

    [ PostgreSQL version number = '9.3' ]

conn=0x198d2e0, query='select oid, typbasetype from pg_type where typname = 'lo''

    [ fetched 0 rows ]

    [ Large Object oid = -999 ]

    [ Client encoding = 'LATIN1' (code = 8) ]

conn=0x198d2e0, query='INSERT INTO TESTTABLE4 (TESTTYPE, TESTCHAR, TESTNUMBER, TESTVARCHAR, testfloat) VALUES ('FLOAT1', '-0.0051'::float8, '-0.0051'::float8, '-0.0051'::float8, '-0.0051'::float8)'

conn=0x198d2e0, query='INSERT INTO TESTTABLE4 (TESTTYPE, TESTCHAR, TESTNUMBER, TESTVARCHAR, testfloat) VALUES ('FLOAT2', '4.5678e+12'::float8, '4.5678e+12'::float8, '4.5678e+12'::float8, '4.5678e+12'::float8)'

 

 

09.03.0400 not OK

========

conn = 0x247f2e0, PGAPI_Connect(DSN='JWIE', UID='jwie', PWD='xxxxx')

Driver Version='09.03.0400,Jan  6 2015'

Global Options: fetch=100, socket=4096, unknown_sizes=0, max_varchar_size=255, max_longvarchar_size=8190

                disable_optimizer=0, ksqo=1, unique_index=1, use_declarefetch=0

                text_as_longvarchar=1, unknowns_as_longvarchar=0, bools_as_char=1 NAMEDATALEN=64

                extra_systable_prefixes='dd_;', conn_settings='(null)' conn_encoding=''

    [ PostgreSQL version string = '9.4.0' ]

    [ PostgreSQL version number = '9.4' ]

conn=0x247f2e0, query='select oid, typbasetype from pg_type where typname = 'lo''

    [ fetched 0 rows ]

    [ Large Object oid = -999 ]

    [ Client encoding = 'LATIN1' (code = 8) ]

conn=0x247f2e0, query='INSERT INTO TESTTABLE4 (TESTTYPE, TESTCHAR, TESTNUMBER, TESTVARCHAR, testfloat) VALUES ('FLOAT1', '-0.00510000018'::float8, '-0.00510000018'::float8, '-0.00510000018'::float8, '-0.00510000018'::float8)'

conn=0x247f2e0, query='INSERT INTO TESTTABLE4 (TESTTYPE, TESTCHAR, TESTNUMBER, TESTVARCHAR, testfloat) VALUES ('FLOAT2', '4.56779996e+12'::float8, '4.56779996e+12'::float8, '4.56779996e+12'::float8, '4.56779996e+12'::float8)'

 

Can you please check this?

Thank you.

 

Best Regards

Jens Wiechmann

 

 

 

 

Jens Wiechmann
> Research and Development

Tel:       + 49 30 9210 24539
Mobile:  + 49 152 56747131
E-mail:  
jens.wiechmann <at> redknee.com
Website:
www.redknee.com
Twitter:  <at> RedkneeRKN
TSX:      RKN



Email Disclaimer

Redknee (Germany) GmbH

Geschäftsführung / Managing Directors: David Charron, Sabine Domes / Sitz der Gesellschaft: Berlin
Registered office: Berlin / Registergericht: Berlin / Commercial register: Berlin, HRB 152437 B

 

 


Gmane