From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: additional json functionality |
Date: | 2013-11-20 18:01:13 |
Message-ID: | 528CF8E9.4010405@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/20/2013 12:50 PM, Greg Stark wrote:
>
> On Sat, Nov 16, 2013 at 12:32 AM, Josh Berkus <josh(at)agliodbs(dot)com
> <mailto:josh(at)agliodbs(dot)com>> wrote:
>
> On 11/15/2013 04:00 PM, David Johnston wrote:
> > Looking at this a different way: could we just implement BSON
> and leave json
> > alone?
> >
> > http://bsonspec.org/
>
> In short? No.
>
> For one thing, our storage format is different from theirs (better,
> frankly), and as a result is not compliant with their "standard".
>
>
> Not being super familiar with either BSON our JSONB what advantages
> are we gaining from the difference?
>
> It might be interesting if we supported the same binary representation
> so we could have a binary send/recv routines that don't need to do any
> serialization/deserialization. Especially since a standard format
> would potentially be skipping the serialization/deserialization on
> both the server and client.
>
>
>
To start with, it doesn't support arbitrary precision numerics. That
means that right off the bat it's only accepting a subset of what the
JSON spec allows. 'Nuff said, I think.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-11-20 18:01:28 | Re: Storage formats for JSON WAS: additional json functionality |
Previous Message | Tom Lane | 2013-11-20 17:55:49 | WITH ORDINALITY versus column definition lists |