Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server
Date
Msg-id Pine.GSO.4.64.0705201933420.13675@westnet.com
Whole thread Raw
In response to Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server  (Shachar Shemesh <shachar@shemesh.biz>)
Responses Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server  (Shachar Shemesh <shachar@shemesh.biz>)
List pgsql-hackers
On Sun, 20 May 2007, Shachar Shemesh wrote:

> This is not data given to store. It's data being exported.

Data being exported has a funny way of turning around and being stored in 
the database again.  It's kind of nice to know the damage done during that 
round trip is minimized.

> Tom seems to think this is not a goal (though, aside from his disbelief
> that such a goal is attainable, I have heard no arguments against it).

If Tom thinks it's not attainable, the best way to convince him otherwise 
would be demonstrate that it's not.  From here, it looks like your 
response to his concerns for the pitfalls he pointed out has been waving 
your hands and saying "no, that can't really be a problem" while making it 
clear you haven't dug into the details.  One reason people use text 
formats for cross-platform exchanges is that getting portable binary 
compatibility for things like floating point numbers is much harder than 
you seem to think it is.

Stepping back for a second, your fundamental argument seem to be based on 
the idea that doing conversions to text is such a performance issue in a 
driver that it's worth going through these considerable contortions to 
avoid it.  Given how many other places performance can be throttled along 
that path, that itself is a position that requires defending nowadays. 
In the typical driver-bound setups I work with, there's plenty of CPU time 
to burn for simple data conversion work because either the network wire 
speed or the speed of the underlying database I/O are the real 
bottlenecks.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: "Karl O. Pinc"
Date:
Subject: Re: Signing off of patches (was Re: Not ready for 8.3)
Next
From: Shachar Shemesh
Date:
Subject: Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server