Re: additional json functionality

On 11/14/2013 12:20 AM, Josh Berkus wrote:
> 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.
text-json could easily be a domain (text + check that it is convertible
to json)

maybe it is even possible to teach pg_upgrade to do this automatically
> There's a strong simplicity argument against that, though ...
I think it confuses most people, similar to how storing 1+1 as
"processing instructions" instead of just evaluationg it and storing 2 :)

OTOH we are in this mess now and have to solve the backwards
compatibility somehow.

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ