Re: jsonpath versus NaN

Oleg Bartunov <obartunov(at)postgrespro(dot)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.

While we certainly *could* choose to extend jsonpath, and/or jsonb
itself, to allow NaN/Inf, I do not think that it's sane to argue that
the standard requires us to do that; the wording in the opposite
direction is pretty clear. Also, I do not find it convincing to
extend jsonpath that way when we haven't extended jsonb. Quite aside
from the ensuing code warts, what in the world is the use-case?

regards, tom lane