Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch
| От | Tom Lane |
|---|---|
| Тема | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch |
| Дата | |
| Msg-id | 27490.1590414212@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost whenextracting epoch (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Ответы |
Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lostwhen extracting epoch
|
| Список | pgsql-hackers |
Peter Eisentraut <peter.eisentraut@2ndquadrant.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
В списке pgsql-hackers по дате отправления: