Re: jsonpath versus NaN

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: jsonpath versus NaN
Дата
Msg-id CA+TgmobNwqNf2=4+sXy5_Y1FpWcxYf7ybkt-dk1dQqSTkB_qGg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: jsonpath versus NaN  (Oleg Bartunov <obartunov@postgrespro.ru>)
Ответы Re: jsonpath versus NaN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jun 18, 2020 at 11:51 AM Oleg Bartunov <obartunov@postgrespro.ru> wrote:
> The problem is that we tried to find a trade-off  between standard and postgres
> implementation, for example, in postgres CAST  allows NaN and Inf, and SQL Standard
> requires .double should works as CAST.

It seems like the right thing is to implement the standard, not to
implement whatever PostgreSQL happens to do in other cases. I can't
help feeling like re-using the numeric data type for other things has
led to this confusion. I think that fails in other cases, too: like
what if you have a super-long integer that can't be represented as a
numeric? I bet jsonb will fail, or maybe it will convert it to a
string, but I don't see how it can do anything else.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: global barrier & atomics in signal handlers (Re: Atomic operations within spinlocks)