Re: jsonb and nested hstore - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: jsonb and nested hstore
Date
Msg-id 52F26D1C.1000102@dunslane.net
Whole thread Raw
In response to Re: jsonb and nested hstore  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: jsonb and nested hstore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 02/05/2014 11:40 AM, Tom Lane wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Wed, Feb 5, 2014 at 10:22 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>> 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.
> I'm with Merlin in thinking that the case for exposing a binary format
> to clients is pretty weak, or at least a convincing use-case has not
> been shown.  Given the concerns upthread about security hazards in the
> patch's existing recv code, and the fact that it's already February,
> switching to "binary is the same as text" may well be the most prudent
> path here.
>
>             

If we do that we're going to have to live with that forever, aren't we? 
I don't see why there should be a convincing case for binary format for 
nested hstore but not for jsonb.

If it were only for arbitrary libpq clietns I wouldn't bother so much. 
To me the main case for binary format is that some people use COPY 
BINARY for efficiency reasons, and I heard tell recently of someone 
working on that as an option for pg_dump, which seems to me worth 
considering.


cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: jsonb and nested hstore
Next
From: Robert Haas
Date:
Subject: Re: Misaligned BufferDescriptors causing major performance problems on AMD