Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 0F91F64FCC5 for ; Mon, 13 Oct 2008 09:34:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 49150-04; Mon, 13 Oct 2008 09:34:38 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from fabaglexfr.fabasoft.com (fabaglexfr.fabasoft.com [192.84.221.196]) by postgresql.org (Postfix) with ESMTP id 2C67064FC08; Mon, 13 Oct 2008 09:34:35 -0300 (ADT) Received: from FABAMAIL.fabagl.fabasoft.com ([10.10.5.136]) by fabaglexfr.fabasoft.com with InterScan Messaging Security Suite; Mon, 13 Oct 2008 14:33:48 +0200 Received: from 192.168.121.105 ([192.168.121.105]) by FABAMAIL.fabagl.fabasoft.com ([10.10.5.135]) with Microsoft Exchange Server HTTP-DAV ;Mon, 13 Oct 2008 12:34:26 +0000 Received: from vie063 by FABAMAIL.fabagl.fabasoft.com; 13 Oct 2008 14:34:03 +0200 Subject: Re: Timestamp with libpq From: Jakob Lechner Reply-To: jakob.lechner@applstrudl.com To: Michael Meskes Cc: Wilhansen Li , pgsql-interfaces@postgresql.org In-Reply-To: <20081013104627.GA23971@feivel.credativ.de> References: <1223884381.3502.10.camel@vie063.fabagl.fabasoft.com> <1223891843.3502.33.camel@vie063.fabagl.fabasoft.com> <20081013104627.GA23971@feivel.credativ.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Organization: appl.strudl Software GmbH Date: Mon, 13 Oct 2008 14:34:02 +0200 Message-Id: <1223901242.3502.54.camel@vie063.fabagl.fabasoft.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-33.el5) X-imss-version: 2.051 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:3 M:2 S:3 R:4 (0.1500 0.1500) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/7 X-Sequence-Number: 6808 Hi Michael, Am Montag, den 13.10.2008, 12:46 +0200 schrieb Michael Meskes: > Please keep in mind that there is no guarantee that your server sends a d= ouble > 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. Yes, you're right. The SLES postgres server transmits timestamps as long long numbers (microseconds since 2000-01-01). > Is there any reason to use a binary transfer?=20 If I use textual transfer I'm losing precision. E.g. for timestamps the returned string from my table is "1955-06-08 00:00:00". Thus I'm restricted to timestamps with a granularity of 1 second. > I would not recommend this in a > general setup. If you just want to avoid some ascii translation hassle, h= ow > about using ecpg instead of libpq? The generic database interface I'm writing is part of a basic library used in our project. The interface serves as an abstraction for accessing different database servers (Postgres, MSSQL, ...). I'm currently working on the postgres implementation of the interface.=20 As far as I've seen using ecpg means to hardcode SQL statements which of course can't be done in a generic library. Thanks for your helpful hints. But it's seems I don't have much choice but to use ascii transfer mode. Best regards Jakob --=20 Jakob Lechner Research & Development appl.strudl Software GmbH Honauerstra=C3=9Fe 4 A-4020 Linz Tel.: [+43] (70) 60 61 62 Fax: [+43] (70) 60 61 62-609 E-Mail: jakob.lechner@applstrudl.com Web: http://www.applstrudl.com Handelsgericht Linz, FN 303988 t