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: http://www.postgresql.org/mailpref/pgsql-hackers
