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

Shachar Shemesh wrote:
> Tom Lane wrote:
>> Shachar Shemesh <shachar(at)shemesh(dot)biz> writes:
>>
>>> I'll reiterate - the problem is not that PG is exporting the internal
>>> ARM FP format. The problem is that the server is exporting the internal
>>> ARM FP format when the server is ARM, and the IEEE format when the
>>> server is Intel. It's not the format, it's the inconsistency.
>>>
>> This is not a bug, it's intentional. While IEEE-spec floats are
>> reasonably interchangeable these days (modulo the endianness issue),
>> other FP formats tend to have different ranges, special cases, etc.
>> If we try to force them to IEEE spec we may have problems with overflow,
>> loss of precision, who knows what.
>>
> Yes, but if we do not then we have a data interchange library that is
> useless for data interchange. I think overflow and precision loss is
> preferable.

I agree in principle that the wire protocol should be
platform-independent. At the very least, if the server always sends in
native format, the client needs to know which format it's receiving and
be able to convert between all formats. Switching to a common format on
all platforms would of course make life easier for client library
developers.

> But sometimes, like now, PG puts me in an impossible position. You are
> essentially telling me "you will get the numbers in an unknown format,
> you will not have any way of knowing whether you got them in a strange
> format or not, nor will you have any docs on what that format is going
> to be". That is no way to treat your driver developers.

You seem to be ignoring the fact that the text format is
platform-independent. That's what for example JDBC uses, and I'd imagine
other interfaces as well. Is it not possible to use text format in OLE
DB, for floating points?

>> (In this context "reliable" means "can reproduce the original datum
>> exactly when transmitted back".)
>>
> Who cares? If you are using the same function for binary communication
> inside the server and for communications to the clients (or, for that
> matter, another server), then there is something wrong in your design.

> What are the "send" functions used for, beside server to client
> communication, anyways? You are asking me to treat the binary data as an
> opaque. Well, I'll counter with a question - what good is that to me?

Imagine an application that does this:

Issue query "SELECT foofloat FROM footable", and store the value to a
variable
Issue "INSERT INTO footable2 VALUES (?)", and send back the same value.

Don't you think footable and footable2 should now have the same value?
If "SELECT * FROM footable, footable2 WHERE foofloat=foofloat" returns 0
rows, I'd be pissed.

It's possible that the conversion within the driver loses some
precision, depending on the data types supported by the language and
platform, but the wire protocol should at least give the driver a chance
to get it right.

> Please note that the current code is useless for communicating binary
> data between two servers, even if they are guaranteed to be of the same
> version! How much less reliable can you get?

The current code is not used for communicating between two servers. And
it works fine as long as the client and the server are on the same platform.

Don't get me wrong, I agree that the binary format is broken as it is,
but the cure mustn't be worse than the disease.

> Please, give your own interface designers something to work with. Your
> attitude essentially leaves me out in the cold.

Design a wire protocol that
1. Doesn't lose information on any platform
2. Is more efficient than text format

and I'm pretty sure it'll be accepted.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com