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

Re: Timestamp with libpq

From: Jakob Lechner <jakob(dot)lechner(at)applstrudl(dot)com>
To: Wilhansen Li <willi(dot)t1(at)gmail(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Timestamp with libpq
Date: 2008-10-13 09:57:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces

Am Montag, den 13.10.2008, 17:32 +0800 schrieb Wilhansen Li:
> Actually, I've done this before. And, uh, you can check out my blog
> for details:

I think I've seen your blog before. Your solution is reasonable but
unfortunately not feasible for me:
I'm writing a simple generic interface for accessing databases and thus
I need to cope with arbitrary SQL statements.
As I posted before I want to execute the statement
"select * from testtable" without any modifications and if there are
timestamp coloumns in the result set I want to convert the timestamp
values to unix time_t values.

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.

Can anybody figure out a reason for this behaviour?

Best regards

Jakob Lechner
Research & Development
appl.strudl Software GmbH
Honauerstra├če 4
A-4020 Linz
Tel.: [+43] (70) 60 61 62
Fax: [+43] (70) 60 61 62-609
E-Mail: jakob(dot)lechner(at)applstrudl(dot)com
Handelsgericht Linz, FN 303988 t

In response to


pgsql-interfaces by date

Next:From: Michael MeskesDate: 2008-10-13 10:46:27
Subject: Re: Timestamp with libpq
Previous:From: Wilhansen LiDate: 2008-10-13 09:32:30
Subject: Re: Timestamp with libpq

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