From: | Chris Gamache <cgg007(at)yahoo(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | timestamp in 7.1 vs 7.2 |
Date: | 2002-05-08 17:48:23 |
Message-ID: | 20020508174823.60544.qmail@web13804.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
data=# begin work;
BEGIN
data=# create temporary table tstest (tsvalue timestamp);
CREATE
data=# insert into tstest (tsvalue) values (current_timestamp);
INSERT 29700913 1
data=# select * from tstest;
tsvalue
-------------------------------
2002-05-08 13:34:23.809817-04
(1 row)
data=# select * from tstest where tsvalue='5/8/02 1:34:23 PM'::timestamp;
tsvalue
---------
(0 rows)
data=# rollback;
ROLLBACK
data=#
=========================================
It seems like we now have microseconds to deal with in the timestamp from 7.1.
(Or I've just been doing most of my timestamp processing on the client-end as
opposed to letting postgresql set them. never gave it the chance to not match
up...)
Unfortunately, ODBC reformats the timestamp to something similar to the above
select...where statement. Can I cast current_timestamp to truncate the
microseconds?
Any other ideas for matching up the data properly? I only need up-to-the-second
resolution on this particular timestamp task.
CG
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2002-05-08 17:53:08 | Re: Performance issues with compaq server |
Previous Message | Jason Earl | 2002-05-08 17:34:45 | Re: Contrib reindex script: |