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  (David Fetter <david@fetter.org>)
Список 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 по дате отправления:

Предыдущее
От: Victor Yegorov
Дата:
Сообщение: Re: Failure to create GiST on ltree column
Следующее
От: Tom Lane
Дата:
Сообщение: Re: repeat() function, CHECK_FOR_INTERRUPTS(), and unlikely()