On 10 February 2014 20:11, Hannu Krosing <ha...@krosing.net> wrote: > The fastest and lowest parsing cost format for "JSON" is tnetstrings > http://tnetstrings.org/ why not use it as the binary wire format ? > > It would be as binary as it gets and still be generally parse-able by > lots of different platforms, at leas by all of these we care about.
If we do go down the binary encoding path in a future release, can I please suggest *not* using something like tnetstrings, which suffers the same problem that a few binary transport formats suffer, particularly when they're developed by people whose native language doesn't distinguish between byte arrays and strings - all strings are considered byte arrays and it's up to an application to decide on character encoding and which things are data vs strings in the application. This makes writing a parser in a language which does treat byte arrays and strings differently very difficult, see e.g. the java tnetstrings API [1] which is forced into treating strings as byte arrays until the programmer then asks it to parse the thing again, but please treat everything as a string this time. The msgpack people after much wrangling have ended up issuing a new version of the protocol which avoids this issue and which they are strongly encouraging users to switch to, see [2] for the gory details. While we may not ever store types in our jsonb format other than the standard json data types (I can foresee people wanting to do it, though), I would strongly recommend picking a format which at least is clear that a value is a string (text, whatever), and preferably makes it clear what the character encoding is. Or maybe it should just follow whatever the client encoding is at the time - as long as that is completely unambiguous to a client. Cheers Tom [1] https://github.com/asinger/tnetstringsj [2] https://github.com/msgpack/msgpack/issues/128 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
