Re: fixes for date_part micro/millisecond precision

On 24 Nov 2001 at 14:24 (-0500), Tom Lane wrote:
| Brent Verner <brent(at)rcfile(dot)org> writes:
| > This patch fixes a problem where extract/date_part returns bad values
| > for microsecond and millisecond parts.
|
| I'm not convinced the existing behavior is wrong. Timestamps are floats
| in PG, and therefore not infinitely precise. Your patch seems to be
| trying to cover this up, but I fear it will only succeed in introducing
| other problems.

<pedantically>
The current bahavior seems to be precise, just not accurate.
</pedantically>

I agree much that my fix is covering over the problem, but something
needs to change (IMO), because if I insert a timestamp of
'2001-1-1 11:11:11.12341234-05' I /really/ want to get back '12341234'
when I ask for the microseconds that I stored, so I can't see how the
current behavior isn't asking for problems in applications that use
these features. After many hours of looking at how to solve this, the
only way I could find to ensure "what I put in is what I get out," was
the change in timestamptz_part().

Anyone have any idea of how (better) to fix this, short of
changing the internal representation of Timestamp to a struct?
Is there a better place to 'force' the accuracy of the fractional
second part that would be less prone to introduce other problems?

thanks.
brent

--
"Develop your talent, man, and leave the world something. Records are
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing." -- Duane Allman