On Tue, Nov 19, 2013 at 11:59 AM, Josh Berkus <josh@agliodbs.com> wrote:
> On 11/19/2013 08:14 AM, Robert Haas wrote:
>> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
>>> I am sure you could also devise an json encoding scheme
>>> where white space is significant ;)
>>
>> I don't even have to think hard. If you want your JSON to be
>> human-readable, it's entirely possible that you want it stored using
>> the same whitespace that was present on input. There is a valid use
>> case for normalizing whitespace, too, of course.
>
> Given that JSON is a data interchange format, I suspect that there are
> an extremely large combination of factors which would result in an
> unimplementably large number of parser settings. For example, I
> personally would have use for a type which allowed the storage of JSON
> *fragments*. Therefore I am interested only in supporting two:
>
> a) the legacy behavior from 9.2 and 9.3 so we don't destroy people's
I'm uncomfortable with the word 'legacy'. This suggests the new type
will essentially deprecate the old type. jsonb will be likely be
pessimal to large serializations. If you're not manipulating and
searching the documents, why would you use it? It's going to take
more space on disk and memory and should provide little benefit for
present *as well as future code* . (note, it will provide extreme
benefits for nosql type uses which is of huge strategic importance for
the project). json and jsonb APIs should work together cleanly, and
the documentation should suggest which types are different and better
for which cases.
merlin