On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams <joeyadams3.14159@gmail.com> wrote:
> Interesting. This leads to a couple more questions:
>
> * Should the JSON data type (eventually) have an equality operator?
+1.
> * Should the JSON input function alphabetize object members by key?
I think it would probably be better if it didn't. I'm wary of
overcanonicalization. It can be useful to have things come back out
in more or less the format you put them in.
> If we canonicalize strings and numbers and alphabetize object members,
> then our equality function is just texteq. The only stumbling block
> is canonicalizing numbers. Fortunately, JSON's definition of a
> "number" is its decimal syntax, so the algorithm is child's play:
>
> * Figure out the digits and exponent.
> * If the exponent is greater than 20 or less than 6 (arbitrary), use
> exponential notation.
>
> The problem is: 2.718282e-1000 won't equal 0 as may be expected. I
> doubt this matters much.
I don't think that 2.718282e-100 SHOULD equal 0.
> If, in the future, we add the ability to manipulate large JSON trees
> efficiently (e.g. by using an auxiliary table like TOAST does), we'll
> probably want unique members, so enforcing them now may be prudent.
I doubt you're going to want to reinvent TOAST, but I do think there
are many advantages to forbidding duplicate keys. ISTM the question
is whether to throw an error or just silently discard one of the k/v
pairs. Keeping both should not be on the table, IMHO.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
