Re: jsonpath versus NaN - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: jsonpath versus NaN
Date
Msg-id CAPpHfdvU4KNrbusUXr_hwv8Jd_GkJx0mzSY0TTAGPsexPxSn+Q@mail.gmail.com
Whole thread Raw
In response to Re: jsonpath versus NaN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: jsonpath versus NaN  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Re: jsonpath versus NaN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom,

On Thu, Jun 18, 2020 at 7:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Oleg Bartunov <obartunov@postgrespro.ru> writes:
> > 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.
>
> As I said, I think this is a fundamental misreading of the standard.
> The way I read it is that it requires the set of values that are legal
> according to the standard to be processed the same way as CAST would.

Thank you for your answer. I'm trying to understand your point.
Standard claims that .double() method should behave the same way as
CAST to double.  However, standard references the standard behavior of
CAST here, not behavior of your implementation of CAST.  So, if we
extend the functionality of standard CAST in our implementation, that
doesn't automatically mean we should extend the .double() jsonpath
method in the same way.  Is it correct?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [patch] demote
Next
From: Fujii Masao
Date:
Subject: Re: Cleanup - Removal of unused function parameter fromCopyReadBinaryAttribute