Re: additional json functionality - Mailing list pgsql-hackers

From Garick Hamlin
Subject Re: additional json functionality
Date
Msg-id 20131114144708.GB16030@isc.upenn.edu
Whole thread Raw
In response to Re: additional json functionality  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
On Wed, Nov 13, 2013 at 04:50:49PM -0800, David E. Wheeler wrote:
> On Nov 13, 2013, at 4:45 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> 
> >> It should be a pretty-printing function option, perhaps, but not core to the type itself, IMO.
> > 
> > I don't in the least understand how it could be a pretty printing option.
> > If we move to a binary rep using the hstore stuff order will be destroyed
> > and not stored anywhere, and duplicate keys will be lost. Once that's done,
> > how would a pretty print option restore the lost info?
> 
> I meant ordering the keys, usually in lexicographic order. I agree that preserving order is untenable.

There is a canonical form.

http://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00

A Canonical form would be very useful.  Thats a bit trickier than sorting the 
keys and I don't know there is an accepted canonical form for json yet that
can represent all json documents.  (The canonical form is not the pretty form, 
but I think the key ordering should be the same.)

It might be nice to have a more general canonical form if one emerges from 
somewhere that could encode any json.  Since without something like this,
hashing can only be well specified for the 'sensible subset of json' used in
security protocols.

Garick



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Clang 3.3 Analyzer Results
Next
From: Tom Lane
Date:
Subject: Re: init_sequence spill to hash table