From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Duplicate JSON Object Keys |
Date: | 2013-03-13 16:40:57 |
Message-ID: | 3E5EE5E6-2013-46B4-8731-F82C7C9E28AD@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar 13, 2013, at 5:17 AM, Robert Haas <robertmhaas(at)gmail(dot)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 the former. 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. Perhaps a note could be added to the docs explaining this difference, and what one can do to adapt for it. A normalizing function would certainly help.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2013-03-13 16:51:42 | Re: Duplicate JSON Object Keys |
Previous Message | Tom Lane | 2013-03-13 15:35:13 | Re: Writable foreign tables: how to identify rows |