Postgres's JSONB inherits the definition of Postgres's string and numeric types.
SQLite's JSONB punts the problem down the line to whoever uses the JSON.
(this all is a reminder that JSON is a horrible format and you should never use it if you care about your data)
Eh, warts abound all over technology and ubiquity is worth a lot.
But because data is important, everybody who does use JSON should make sure they serialize their data in a way the format won’t break. I’ve heard it can be done.
That one simple rule ensures your data won't be clobbered and you program won't crash.
(And yes, your serialization/deserialization code will need to contain explicit string conversions. But even with that extra conversion, Javascript is way more interoperable with anything and future-proof than any alternative like protobuf or msgpack)
https://www.postgresql.org/docs/current/functions-xml.html
Iirc XML support in Postgres predates JSON support.
I think there a two good variants of binary JSON equivalents: one where you have a minimal implementation that makes both reading and writing with the lowest amount of code possible, potentially feeding a SAX-like interface or constructing an in memory representation (DOM-style).
The other one would be to facilitate lookups in large documents such as json_extract without parsing the whole document. That would require some clever layout of the data, potentially even as in-file hash tables or similar. I assume that is what SQLite has done.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I could say many things about it, but "simplest possible" is not one of them.
"Simple" in that it's trivial to decode with a bytestream and a jump table, and it can be written down very briefly.
https://github.com/civboot/civlua/blob/main/zoa/README.md
It's still in it's initial stages, but I'd love feedback :D
Can you elaborate on this? It seems pretty clear from the spec to me: stuff starting with " is a string, stuff starting with - or a digit is a number.
Min value? Max value? Precision (and in what base)?
Anything else is non-standard.
PostgreSQL also doesn't follow your "standard".
Don't know what a "Datadog" is, and I don't care about Postgres idiosyncrasies.
> A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part.
> This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.
That sure doesn't sound like numbers are 64 bit floats, according to the spec.
It can't be 64 bit floats, because they are represented as decimal numbers, not binary. You will be surprised to also hear that most base conversion algorithms used are not exact, and so different implementations might give different results in the LSB(s) for some numbers for performance reasons. Here practicality prevails, because making the standard stricter would make its implementation much harder in many environments. And for many applications it isn't a problem. I am sure btw that most file formats that use decimal representations for floating point numbers have this property, otherwise exact base conversion would be more prominently accessible in more programming languages.
I have some hope that this will change in the future, as exact base conversion (lossless round trip) will gain momentum now that it landed in standard C++. Once most common programming languages have this feature, there isn't a big reason to not modify the standard anymore to enforce lossless round-trip.
I got that.
> JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [1].
I don't know what you mean by controls (you mean unicode control characters, for which the spec explicitly states that they are to be escaped?), but since JSON should really only be exchanged as UTF-8, surrogate pairs play no role.
Works on my machine.