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

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server
Дата
Msg-id Pine.GSO.4.64.0705201933420.13675@westnet.com
обсуждение исходный текст
Ответ на Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server  (Shachar Shemesh <shachar@shemesh.biz>)
Ответы Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server  (Shachar Shemesh <shachar@shemesh.biz>)
Список 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 по дате отправления:

Предыдущее
От: "Karl O. Pinc"
Дата:
Сообщение: Re: Signing off of patches (was Re: Not ready for 8.3)
Следующее
От: Shachar Shemesh
Дата:
Сообщение: Re: Re: [Oledb-dev] double precision error with pg linux server, but not with windows pg server