Re: Timestamp with libpq
От | Jakob Lechner |
---|---|
Тема | Re: Timestamp with libpq |
Дата | |
Msg-id | 1223891843.3502.33.camel@vie063.fabagl.fabasoft.com обсуждение исходный текст |
Ответ на | Re: Timestamp with libpq ("Wilhansen Li" <willi.t1@gmail.com>) |
Ответы |
Re: Timestamp with libpq
|
Список | pgsql-interfaces |
Hello, 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: > > > http://blogs.crammerz-inc.net/thunk/2007/05/09/grabbing_time_in_postgresql_using_libpq 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 -- 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.lechner@applstrudl.com Web: http://www.applstrudl.com Handelsgericht Linz, FN 303988 t
В списке pgsql-interfaces по дате отправления: