On Tue, Nov 19, 2013 at 12:59 PM, Josh Berkus <j...@agliodbs.com> wrote:
> On 11/19/2013 08:14 AM, Robert Haas wrote:
>> On Thu, Nov 14, 2013 at 2:54 PM, Hannu Krosing <ha...@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
> 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.

For (a), I assume you mean "whitespace not significant, but
preserved", because that is the current behavior, whereas for (b), I
think we would want to say "whitespace neither significant nor
preserved".  Other than that, I completely agree.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to