Well... It wouldn't have to be ASCII, right? As long as the way it is
communicated between server and client is standardized. On the server
side, each type has a _send() and _recv() method that performs a
conversion from the internal representation on the server side to a
standard representation that is used for communication with the client, if
I'm not mistaken.
For instance, the int4 type is send in network byte order by the server,
even if this is not the native byte order of the architecture on which the
server is compiled/ran.
If the client, i.e. libpq, would just convert back from this standard
format to the byte order used on the host architecture everything should
be nicely transparent. But from the libpq examples it seems libpq does not
do this. Come to think of it, wouldn't it be possible to re-use the
implementation of the _send/_recv methods from the server to perform the
necessary conversion on the client side?
I suppose that something similar should be possible with floating point
types, although it might be more involved.
On Wed, January 17, 2007 4:46 pm, Bruce Momjian wrote:
> Joris van Zwieten wrote:
>> Hi Bruce, Jeroen,
>> Thanks for your replies. This is good to know, although one worry
>> remains and that is loss of precision in the conversion of double to
>> string. But this could probably always be solved by using enough digits
>> in the conversion, right?
> Also, the client and server can be different architectures, so the only
> portable way to do the transfer is ASCII.
> Bruce Momjian bruce(at)momjian(dot)us
> EnterpriseDB http://www.enterprisedb.com
> + If your life is a hard drive, Christ can be your backup. +
In response to
pgsql-interfaces by date
|Next:||From: Jeff Davis||Date: 2007-01-24 19:03:21|
|Subject: ruby-postgres module needs work, maintainer gone|
|Previous:||From: Bruno Wolff III||Date: 2007-01-17 17:40:01|
|Subject: Re: Array handling in libpq|