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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-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

Browse pgsql-general by date

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

Browse pgsql-hackers by date

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