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

Re: [HACKERS] Re: [GENERAL] date_part bug?

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Tim Williams <williams(at)ugsolutions(dot)com>
Cc: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, pgsql-general(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [GENERAL] date_part bug?
Date: 1998-12-18 15:18:32
Message-ID: 367A7248.4E435FD9@alumni.caltech.edu (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
> Not all glibc2: I run glibc2 Debian Linux and do not see this problem.
> I was wondering if it was libc5 that was giving trouble...

Not on my libc5-only machine (where I developed the code). We'll need to
get a reproducible case to be able to track it down. I'm guessing that
we are seeing float->int rounding problems, though I don't know why this
test query should show different results for the two columns.

What glibc2, compiler, and optimization level are you using? If you are
using anything above -O2 try backing down to that; if you are already
there then try -O0 and tell us what changes.

                      - Tom

postgres=> create table tmp (v1 date, v2 datetime);
CREATE
postgres=> insert into tmp values ('06-01-1999', '06-01-1999');
INSERT 901482 1
postgres=> select date_part('month', v1) as m1, date_part('month', v2)
as m2 from tmp;
m1|m2
--+--
 6| 6
(1 row)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-12-18 16:07:17
Subject: Re: [HACKERS] Upgrades for 6.4.1
Previous:From: Jan WieckDate: 1998-12-18 15:07:43
Subject: Fixed outfuncs

pgsql-general by date

Next:From: Bruce MomjianDate: 1998-12-18 18:04:23
Subject: Re: [GENERAL] Announce: PyGreSQL 2.2
Previous:From: Valerio SantinelliDate: 1998-12-18 15:11:09
Subject: Slow Searches using MSAccess and ODBC to a PostGreSQL database

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