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 по дате отправления: