Hi guys of the pgsql-hackers list.
I've received a bug report on the OLE DB list, which I suspect is
actually a server bug. The correspondence so far is listed further on,
but, in a nutshell, user runs an OLE DB client on windows (OLE DB uses
the binary interface), and server version 8.1.9 on Windows, and all is
fine. When the server is switched to 8.1.8 on Debian Etch on ARM9,
float8 type is not received properly by OLE DB.
Since OLE DB doesn't really care what version the server is running, the
chances of this being a server side bug are really high. I don't know
ARM9 well enough to comment on floating point format there.
Julian Heeb wrote:
> Shachar Shemesh schrieb:
>> Julian Heeb wrote:
>>> Our acounting software can use the PostgreSQL OLE DB driver to access
>>> a postgreSQL database. With the pg server installed on windows,
>>> everything works fine.
>>> I moved now the database to a postgreSQL server on a linux server, but
>>> now every floating point number gets wrongly interpreted by the
>>> acounting software, either by replacing it with a 0 or a very large
>>> number (e.g. xxxE+308). Only the floating point numbers are affected,
>>> integer or characters are correct. pgAdmin shows even the fp numbers
>>> correctly, so I guess it has something to do with the pgoledb driver.
>>> Can someone give me a hint, how to solve the problem?
>> It's hard to give a precise answer. Let's try a couple of venues.
>> First of all, what platform is the Linux server? Is that an Intel, or
>> something else?
> It is an ARM9 platform with Debian Etch (Linkstation Pro Fileserver with
>> Also, what is the precise type of the floating point var on the server?
>> Can you give the SQL line that generated the table?
> The table has been generated by the following SQL line. The problem
> occures at the double precision fields.
I have some bad news. This is the comment in the Postgresql source code.
This seems to be a core problem at the server side of things:
> /* --------------------------------
> * pq_sendfloat8 - append a float8 to a StringInfo buffer
> * The point of this routine is to localize knowledge of the external
> * representation of float8, which is a component of several datatypes.
> * We currently assume that float8 should be byte-swapped in the same way
> * as int8. This rule is not perfect but it gives us portability across
> * most IEEE-float-using architectures.
> * --------------------------------
Could it be that ARM9 is not IEEE float standard? Can anyone from the
"hackers" list give any insight into this? The function for the data
type import on the client side seems to be in order (switch the byte
order around, and assume it's a valid "double" C type).
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-05-19 17:41:47|
|Subject: Re: COPY into a view; help w. design & patch |
|Previous:||From: Florian G. Pflug||Date: 2007-05-19 15:51:29|
|Subject: Re: Not ready for 8.3|