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. Maybe there's a case for extending json(b) that way; it wouldn't be so different from the work I'm doing nearby to extend type numeric for infinities. But we'd have to have a conversation about whether interoperability with other JSON implementations is worth sacrificing to improve consistency with our float and numeric datatypes. In the meantime, though, we aren't allowing Inf/NaN in json(b) so I don't think jsonpath should accept them either. regards, tom lane