Re: BUG #6391: insert does not insert correct value - Mailing list pgsql-bugs

From John Udick
Subject Re: BUG #6391: insert does not insert correct value
Date
Msg-id BEC72D0140FBF24EB055A6D15F47FADC105A210CF0@UTEXVS02.zbc.internal
Whole thread Raw
In response to Re: BUG #6391: insert does not insert correct value  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Vic
Date:
Subject: Re: BUG #6392: leak memory while restore/load dump
Next
From: r d
Date:
Subject: Weird message when creating PK constraint named like table