Show HN: BSON Extension for Postgres(github.com) JSON support in postgres is superb but sometimes you really want decimal, date, and binary types, "carefree" UTF8 string handling (i.e. no escaping), and robust roundtrippability. So I made an extension for BSON. |
https://github.com/buzzm/postgresbson/blob/main/pgbson--2.0....
and this:
https://github.com/buzzm/postgresbson/blob/main/pgbson.c
Really nice stuff.
It is not meant for large reporting formats like live charts etc. These parsers can be unstable if they ignore type checks, precedence, and nesting depth.
The original libbson author wouldn't give me a donation link on inquiry, as they probably thought it was some sort of scam. The library merged into mongoDB years ago. Would not touch mongoDB now days given its current license, and propensity to implode key structures on upgrades. =)
This part is misinformation, as json[b] works perfectly fine with decimals (well, Numeric, which is an arbitrary precision decimal type)
It might help to find if it was the actual query or the de-serialization that was the bottleneck.
I'm wondering if there are any plans to support Postgres versions 15 and 16?
Either way, like I said, JSONB and BSON are solving slightly different problems—you probably would not choose BSON if you don't need the extra data types, and if you do need the extra data types JSONB can't help you any more than JSON can.
But this also affect decoding. Not prefixed with size means the memory size you need to allocate is unknown at the time of decoding. You may need to allocate more than required amount of memory or grow on demand if you don't know the size at the time that decoding starts.
Beside this, BSON is also an exchange format. There is full spec and you can use it outside of mongodb. (For example, you need to write an object that contains ArrayBuffer to disk? Just serialize it as BSON and write to disk.) While jsonb in progress is just a DB internal representation, you don't actually see the binary format anywhere.
I don't think so. Arrays and documents store the number of elements before the data and don't use a terminator value. Only element names are nul terminated strings.
But how is that relevant? With BSON as transfer format you still don't have that guarantee that the client won't misinterpret the data it receives by using bfl8 as its own internal data format after deserialization.
All languages I know have libraries that can decode the numbers from JSON strings into their relevant arbitrary-precision decimal type. If the user doesn't use that, why would it be a failure of JSON[B]/PostgreSQL?
[0] https://www.mongodb.com/docs/manual/reference/bson-types/