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

Re: Timestamp with libpq

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: Jakob Lechner <jakob(dot)lechner(at)applstrudl(dot)com>
Cc: Wilhansen Li <willi(dot)t1(at)gmail(dot)com>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Timestamp with libpq
Date: 2008-10-13 10:46:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
On Mon, Oct 13, 2008 at 11:57:23AM +0200, Jakob Lechner wrote:
> I just wonder why my conversion routine for the binary timestamps
> returned from a postgres server running on RHEL works while it's not for
> a SLES server. Apparently the same SQL statement executed by exactly the
> same libpq API calls produces different results for the two postgres
> servers, one running on RHEL and another on SLES. Both postgres servers
> basically have the same version (8.1.4). The program that executes the
> SQL statement runs on my workstation and either connects to my RHEL
> server or to my SLES machine.

Please keep in mind that there is no guarantee that your server sends a double
in a binary query. This depens on whether integer-datatypes are configure or
not. Or in other words, it might be a long long instead of a double.

Is there any reason to use a binary transfer? I would not recommend this in a
general setup. If you just want to avoid some ascii translation hassle, how
about using ecpg instead of libpq? It will take care of everything you need.


Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes(at)jabber(dot)org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

In response to


pgsql-interfaces by date

Next:From: Jakob LechnerDate: 2008-10-13 12:34:02
Subject: Re: Timestamp with libpq
Previous:From: Jakob LechnerDate: 2008-10-13 09:57:23
Subject: Re: Timestamp with libpq

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