> It's a decent amount of work to define one though... It's clearly not
> acceptable to just dump out the internal representation, as already discussed
> in this thread.
I totally agree that it should be a well-defined format that doesn't
leak stuff like endianness and alignment of the underlying database.
With a bit of googling I found the UBJSON specification:
https://ubjson.org/#data_format
It seems like it would be possible to transform between JSONB and
UBJSON efficiently. As an example: For my recent use case the main
thing that was slow was parsing JSON strings, because of the escape
characters. That's not needed with UBJSON, because strings are simply
UTF-8 encoded binary data, that are prefixed with their length. So all
that would be needed is checking if the binary data is valid UTF-8.
Also there seem to be implementations in many languages for this spec:
https://ubjson.org/libraries/ So, that should make it easy for
Postgres client libraries to support this binary format.
> I'm still bemused by the proposition that that common interchange format
> shouldn't be, um, JSON. We've already seen BSON, BJSON, etc die
> well-deserved deaths.
@Tom Lane: UBJSON calls explicitly lists these specific failed
attempts at a binary encoding for JSON as the reason for why it was
created, aiming to fix the issues those specs have:
https://github.com/ubjson/universal-binary-json#why
Jelte