On 11/19/2013 12:59 PM, Josh Berkus 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.



Fragments are currently allowed in a):

   andrew=# select '"a"'::json;
     json
   ------
     "a"


Given that, I'm not sure we shouldn't permit them in b) either. I think I lost that argument back in the 9.2 dev cycle. I really don't want to get to a situation where foo::json::jsonb can produce an error.

cheers

andrew


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

Reply via email to