On Thu, Jun 18, 2020 at 7:45 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alexander Korotkov <a.korot...@postgrespro.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
