Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

2017-02-09 Thread Erik Nordström
Tom, You are of course right that you cannot add precision that was not there to begin with. My patch does nothing for input values that cannot be represented accurately to begin with. However, that was not my main point. The idea with the calculation is this: When you remove the

Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

2017-02-09 Thread Erik Nordström
Hi Tom, and others, Thanks for the insightful feedback. You are right, the patch does suffer from overflow (and other possible issues when I think about it). Using rint(), as you suggest, helps in my original example case, but there are still cases when the output is not what you would expect.

Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

2017-02-09 Thread Tom Lane
=?UTF-8?Q?Erik_Nordstr=C3=B6m?= writes: > Thanks for the insightful feedback. You are right, the patch does suffer > from overflow (and other possible issues when I think about it). Using > rint(), as you suggest, helps in my original example case, but there are > still

Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

2017-02-08 Thread Tom Lane
I wrote: > I wonder if we could make things better just by using rint() rather than > a naive cast-to-integer. The cast will truncate not round, and I think > that might be what's mostly biting you. Does this help for you? > #ifdef HAVE_INT64_TIMESTAMP > - result = seconds *

Re: [HACKERS] Patch: Avoid precision error in to_timestamp().

2017-02-08 Thread Tom Lane
=?UTF-8?Q?Erik_Nordstr=C3=B6m?= writes: > I stumbled upon a precision issue with the to_timestamp() function that > causes it to return unexpected timestamp values. For instance, the query > SELECT to_timestamp(1486480176.236538) returns the timestamp "2017-02-07 >

[HACKERS] Patch: Avoid precision error in to_timestamp().

2017-02-08 Thread Erik Nordström
Hello hackers, I stumbled upon a precision issue with the to_timestamp() function that causes it to return unexpected timestamp values. For instance, the query SELECT to_timestamp(1486480176.236538) returns the timestamp "2017-02-07 16:09:36.236537+01", which is off by one microsecond. Looking at