From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Terry Laurenzo <tj(at)laurenzo(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |
Date: | 2010-10-19 14:57:30 |
Message-ID: | 4CBDB1DA.8090003@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/19/2010 10:44 AM, Robert Haas wrote:
> On Sat, Oct 16, 2010 at 12:59 PM, Terry Laurenzo<tj(at)laurenzo(dot)org> wrote:
>> - It is directly iterable without parsing and/or constructing an AST
>> - It is its own representation. If iterating and you want to tear-off a
>> value to be returned or used elsewhere, its a simple buffer copy plus some
>> bit twiddling.
>> - It is conceivable that clients already know how to deal with BSON,
>> allowing them to work with the internal form directly (ala MongoDB)
>> - It stores a wider range of primitive types than JSON-text. The most
>> important are Date and binary.
> When last I looked at that, it appeared to me that what BSON could
> represent was a subset of what JSON could represent - in particular,
> that it had things like a 32-bit limit on integers, or something along
> those lines. Sounds like it may be neither a superset nor a subset,
> in which case I think it's a poor choice for an internal
> representation of JSON.
Yeah, if it can't handle arbitrary precision numbers as has previously
been stated it's dead in the water for our purposes, I think.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2010-10-19 14:57:47 | Re: Extensions, this time with a patch |
Previous Message | Robert Haas | 2010-10-19 14:44:44 | Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP) |