Skip site navigation (1) Skip section navigation (2)

Re: Array handling in libpq

From: "Joris van Zwieten" <vanzwieten(at)stcorp(dot)nl>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: vanzwieten(at)stcorp(dot)nl, "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Array handling in libpq
Date: 2007-01-17 19:39:09
Message-ID: 55030.192.87.1.229.1169062749.squirrel@control.prolocation.net (view raw or flat)
Thread:
Lists: pgsql-interfaces
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.
Bye,

Joris

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 DavisDate: 2007-01-24 19:03:21
Subject: ruby-postgres module needs work, maintainer gone
Previous:From: Bruno Wolff IIIDate: 2007-01-17 17:40:01
Subject: Re: Array handling in libpq

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group