| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | 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 |
| Date: | 2020-05-25 13:43:32 |
| Message-ID: | 27490.1590414212@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2020-05-25 15:43:14 | BUG #16460: Error when executing REFRESH MATERIALIZED VIEW WITH DATA; |
| Previous Message | Peter Eisentraut | 2020-05-25 13:28:54 | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-05-25 13:52:13 | Re: repeat() function, CHECK_FOR_INTERRUPTS(), and unlikely() |
| Previous Message | Victor Yegorov | 2020-05-25 13:41:49 | Re: Failure to create GiST on ltree column |