On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> I'm actually surprised we have an alternate binary wire format for
>> jsonb at all; json is explicitly text and I'm not sure what the use
>> case of sending the internal structure is. Meaning, maybe jsonb
>> send/recv should be a thin wrapper to sending the json string. The
>> hstore send/recv I think properly covers the case where client side
>> binary wire format actors would want to manage performance critical
>> cases that want to avoid parsing.
>
> The whole reason we have jsonb is to avoid reparsing where possible
Sure; but on the server side. The wire format is for handling client
concerns. For example, the case you're arguing for would be for libpq
client to extract as jsonb as binary, manipulate it on a binary level,
then send it back as binary. I find this case to be something of a
stretch.
That being said, for binary dump/restore perhaps there's a performance
case to be made.
> In fact, I'd rather have the send and recv functions in the jsonb code and have
> hstore's functions call them, so we don't duplicate code.
yeah. Agree that there needs to be two sets of routines, not three.
I think a case could be made for the jsonb type could take either
json's or hstore's depending on if the above. FWIW, either way is
fine.
merlin