Re: additional json functionality

From: Robert Haas <robertmhaas(at)gmail(dot)com>
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 22:07:16
Message-ID: CA+TgmoagjFfJst=9kSu4rZatCE8SRuOQCH_h-_YW=4_c687GTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 20, 2013 at 12:50 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
>> 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?

BSON assumes, for example, that all integers fit in 64-bits and all
floating point values can be accurately represented as float8. So not
all JSON objects can be represented as BSON without loss of
information.

BSON also adds a bunch of extra types that are not part of JSON, like
timestamps, regular expressions, and embedded documents. So not all
BSON objects can be represented as JSON without loss of information.

While it's tempting to think that BSON is a serialization format for
JSON, and the name is meant to suggest that, it really isn't. It's
just a serialization format for approximately whatever the authors
thought would be useful, which happens to be kinda like JSON. Sorta.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2013-11-20 22:38:14 Re: Proof of concept: standalone backend with full FE/BE protocol
Previous Message Kevin Grittner 2013-11-20 22:03:52 Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block