On 11/13/2013 04:58 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan <and...@dunslane.net> wrote:
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objects that hstore cannot -- at least
not without extra scaffolding (at least, AIUI, I haven't fully
grappled with the coming hstore stuff yet). In other words, just
because key order and cardinality is unimportant in an associative
array, it does not in any way follow it is similarly unimportant for
object serialization.
An object is an unordered collection ofz ero or more name/value
pairs
...
The names within an object SHOULD be unique.
Forcing us to preserve order and key duplication would be a pretty effective
barrier to any performance improvements.
SHOULD != MUST. Here is the definition of object per RFC 4627.
"An object structure is represented as a pair of curly brackets
surrounding zero or more name/value pairs (or members). A name is a
string. A single colon comes after each name, separating the name
from the value. A single comma separates a value from a following
name. The names within an object SHOULD be unique."
And SHOULD means
"3. SHOULD. This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."
As far as I'm concerned, that settles things right there. Beyond that
(although they do say 'unordered' above), as a consequence of your
argument the json strings {"a": 1, "b": 2} and {"b": 1, "a": 2} should
be considered equivalent. Another consequence is that creating
particular legal constructions should be discouraged. I disagree with
this.
This is simply not the case with many json consuming clients. It's a
nice idea but not how things work universally and that's exactly why
the rules were hedged in the RFC. I have a couple of cases right now
where I'm producing key order sensitive json for some (admittedly not
very well designed) json consuming clients that are out of my control.
I understand the difference between "should" and "must". But there is
nothing that REQUIRES us to preserve key order or duplicate keys. If you
really need textual preservation, you should probably store the data as
text and convert it to json to do json-ish things to it. If not, we're
going to face huge demands to implement another type which almost
everyone but you will move to in rapid order because it performs so much
better. The strong consensus I have seen in discussions at conferences
and elsewhere is to go the way we're going, instead.
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
