From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: additional json functionality |
Date: | 2013-11-13 23:20:22 |
Message-ID: | 52840936.50907@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin,
> I use pg/JSON all over the place. In several cases I have to create
> documents with ordered keys because the parser on the other side wants
> them that way -- this is not a hypothetical argument. The current
> json serialization API handles that just fine and the hstore stuff
> coming down the pike will not. I guess that's a done deal based on
> 'performance'. I'm clearly not the only one to have complained about
> this though.
It's not just a matter of "performance". It's the basic conflict of
JSON as document format vs. JSON as data storage. For the latter,
unique, unordered keys are required, or certain functionality isn't
remotely possible: indexing, in-place key update, transformations, etc.
XML went through the same thing, which is part of how we got a bunch of
incompatible "dialects" of XML.
Now, your use case does show us that there's a case to be made for still
having text JSON even after we have binary JSON. There's a strong
simplicity argument against that, though ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-11-13 23:37:28 | -d option for pg_isready is broken |
Previous Message | Mike Blackwell | 2013-11-13 23:10:12 | Re: additional json functionality |