From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: jsonpath versus NaN |
Date: | 2020-06-18 17:04:10 |
Message-ID: | CAPpHfdtP6Y2dH6_WG-1xEj+GHJ6mdbWA3O+y5tFEBunQdA_SPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 18, 2020 at 7:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> > 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?
>
> Right. We could, if we chose, extend jsonpath to allow Inf/NaN, but
> I don't believe there's an argument that the spec requires us to.
>
> Also the larger point is that it doesn't make sense to extend jsonpath
> that way when we haven't extended json(b) that way. This code wart
> wouldn't exist were it not for that inconsistency. Also, I find it hard
> to see why anyone would have a use for NaN in a jsonpath test when they
> can't write NaN in the input json data, nor have it be correctly reflected
> into output json data either.
Ok, I got the point. I have nothing against removing support of NaN
in jsonpath as far as it doesn't violates the standard. I'm going to
write the patch for this.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-06-18 17:05:41 | Re: More tzdb fun: POSIXRULES is being deprecated upstream |
Previous Message | Fujii Masao | 2020-06-18 16:55:35 | Re: [patch] demote |