On 03/13/2013 12:40 PM, David E. Wheeler wrote:
> On Mar 13, 2013, at 5:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
>> What I think is tricky here is that there's more than one way to
>> conceptualize what the JSON data type really is. Is it a key-value
>> store of sorts, or just a way to store text values that meet certain
>> minimalist syntactic criteria? I had imagined it as the latter, in
>> which case normalization isn't sensible. But if you think of it the
>> first way, then normalization is not only sensible, but almost
>> obligatory.
> That makes a lot of sense. Given the restrictions I tend to prefer in my database data types, I had imagined it as
theformer. And since I'm using it now to store key/value pairs (killing off some awful EAV implementations in the
process,BTW), I certainly think of it more formally as an object.
>
>
> But I can live with the other interpretation, as long as the differences are clearly understood and documented.
Perhapsa note could be added to the docs explaining this difference, and what one can do to adapt for it. A normalizing
functionwould certainly help.
I guess the easiest and most generic way to normalize is to actually
convert to some internal representation and back.
in pl/python this would look like this:
hannu=# create function normalize(IN ij json, OUT oj json) language
plpythonu as $$
import json
return json.dumps(json.loads(ij))
$$;
CREATE FUNCTION
hannu=# select normalize('{"a":1, "a":"b", "a":true}'); normalize
------------- {"a": true}
(1 row)
If we could want to be really fancy we could start storing our json in
some format which
is faster to parse, like tnetstrings, but probably it is too late in
release cycle to change this now.
Hannu
>
> Best,
>
> David
>
