Re: BUG #6391: insert does not insert correct value
От | John Udick |
---|---|
Тема | Re: BUG #6391: insert does not insert correct value |
Дата | |
Msg-id | BEC72D0140FBF24EB055A6D15F47FADC105A210CF0@UTEXVS02.zbc.internal обсуждение исходный текст |
Ответ на | Re: BUG #6391: insert does not insert correct value (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Following the example provided, this still appears to be a bug. The results= are very different when we run the example. We did notice that although no= w() failed, changing this to 'now()'::date works (using single quotes aroun= d now()). I will be working with our administrators to review patches and v= ersion levels.=20 Also, apparently we are not truly a Postgres database, but EMC's Greenplum = database. I will be working with our admins and EMC, unless someone in Post= gres can point out a specific version that resolved this issue.=20 drop table if exists t; create table t=20 (id int primary key,=20 d1 date not null,=20 d2 date not null); =20=20=20 insert into t values (1, now(), current_date), (2, localtimestamp::date, date_in(date_out(current_date))), (3, 'now()'::date, clock_timestamp()::DATE); select * from t order by 1; id | d1 | d2=20=20=20=20=20 ----+------------+------------ 1 | 1999-12-31 | 1999-12-31 2 | 1999-12-31 | 1999-12-31 3 | 2012-01-11 | 2012-01-11 Additional information - select version(); "PostgreSQL 8.2.15 (Greenplum Database 4.1.1.5 build 1) on x86_64-unknown-l= inux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Sep 20 2011 11:09:08" John Udick | Enterprise Data Warehouse Development -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20 Sent: Wednesday, January 11, 2012 8:21 AM To: John Udick Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #6391: insert does not insert correct value=20 john.udick@zionsbancorp.com writes: > I would expect that at the time/date of the of now() and clock_timestamp() > to be equal; which they are. Well, they are not in general, but that doesn't appear to be your problem. You have not shown us a reproducible test case, but I wonder whether your table has a trigger that is doing date_trunc('year',...) or something like that on the column value. regards, tom lane =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D THIS ELECTRONIC MESSAGE, INCLUDING ANY ACCOMPANYING DOCUMENTS, IS CONFIDENT= IAL and may contain information that is privileged and exempt from disclosu= re under applicable law. If you are neither the intended recipient nor resp= onsible for delivering the message to the intended recipient, please note t= hat any dissemination, distribution, copying or the taking of any action in= reliance upon the message is strictly prohibited. If you have received thi= s communication in error, please notify the sender immediately. Thank you.
В списке pgsql-bugs по дате отправления: