Re: additional json functionality

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

In response to

Browse pgsql-hackers by date

  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