Re: additional json functionality

On 11/19/2013 08:14 AM, Robert Haas wrote:
> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)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
apps, and

b) the optimal behavior for Hstore2/JSONB.

(a) is defined as:
* complete documents only (no fragments)
* whitespace not significant
* no reordering of keys
* duplicate keys allowed

(b) is defined as:
* complete documents only (no fragments)
* whitespace not significant
* reordering of keys
* duplicate keys prohibited

If people want other manglings of JSON, they can use TEXT fields and
custom parsers written in PL/v8, the same way I do.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com