|From:||David Fetter <david(at)fetter(dot)org>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Petr Fedorov <petr(dot)fedorov(at)phystech(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Mon, May 25, 2020 at 09:43:32AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> > One problem (other than perhaps performance, tbd.) is that this would no
> > longer allow processing infinite timestamps, since numeric does not
> > support infinity. It could be argued that running extract() on infinite
> > timestamps isn't very useful, but it's something to consider explicitly.
> I wonder if it's time to fix that, ie introduce +-Infinity into numeric.c.
> This isn't the first time we've seen issues with numeric not being a
> superset of float, and it won't be the last.
> At first glance there's no free bits in the on-disk format for numeric,
> but we could do something by defining the low-order bits of the header
> word for a NaN to distinguish between real NaN and +/- infinity.
> It looks like those bits should reliably be zero right now.
+1 for adding +/- infinity to NUMERIC.
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
|Next Message||PG Bug reporting form||2020-05-25 19:54:39||BUG #16461: Segfault in autovacuum process|
|Previous Message||Tom Lane||2020-05-25 17:35:04||Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch|
|Next Message||Chapman Flack||2020-05-25 19:32:52||Re: what can go in root.crt ?|
|Previous Message||Chapman Flack||2020-05-25 19:15:48||what can go in root.crt ?|