Re: fixes for date_part micro/millisecond precision

> ... 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