Re: WIP Patch: Add a function that returns binary JSONB as a bytea
От | Jelte Fennema |
---|---|
Тема | Re: WIP Patch: Add a function that returns binary JSONB as a bytea |
Дата | |
Msg-id | CAGECzQQX-CiGqHE3204jw8qbOX0kD-XtaamV=wvaiMqS0P55VQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP Patch: Add a function that returns binary JSONB as a bytea (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
> 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
В списке pgsql-hackers по дате отправления: