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

Re: fixes for date_part micro/millisecond precision

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Brent Verner <brent(at)rcfile(dot)org>
Cc: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, pgsql-patches(at)postgresql(dot)org
Subject: Re: fixes for date_part micro/millisecond precision
Date: 2001-11-28 03:40:05
Message-ID: 3C045C95.2E5FD732@fourpalms.org (view raw or flat)
Thread:
Lists: pgsql-patches
> ... The behavior
> still seems wrong, since it gives me back something that I did not
> put in.  Additionally, I can get back a value that I /can't/ put back
> in the database.  I do agree with Tom that my solution was simply
> a cover-up.  The SQL-99 spec says nothing of MILLI or MICROSECONDS,
> so I'm curious if there is interest in really fixing the date_part
> behavior WRT fractional seconds.  Comments Thomas?

You are exploring the downside of using float8 for timestamp storage.
This has not been a major issue until now (and may not be for most
users) but since we now allow more than two decimal places in the output
format it becomes more obvious.

> The only way I can see to fix it is to make Timestamp a struct
> something like...

Yuck. That *may* be how other databases do it, but having to carry along
multiple fields complicates the math and comparison functions, and slows
down the code.

I have been thinking of implementing timestamp (and other related types)
as 8 byte integers, which are not slow on some platforms. doubles are
fast on most platforms nowadays. The tradeoff will be repeatability vs
range, since we will not get the quasi-infinite range we have now when
using a fixed decimal type. We could have a third option, which uses 4
byte integers in structures, which you proposed. But that seems the
least desirable for the long run.

If I do this it will be as a configurable option, at least at first.

                       - Thomas

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2001-11-28 04:44:05
Subject: Re: fixes for date_part micro/millisecond precision
Previous:From: Thomas LockhartDate: 2001-11-28 03:07:30
Subject: Re: Support for QNX6, POSIX IPC and PTHREAD-style locking

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