Re: additional json functionality - Mailing list pgsql-hackers

On 11/14/2013 04:07 PM, Merlin Moncure wrote:
> On Wed, Nov 13, 2013 at 6:01 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
>>
>> I guess we should not replace current JSON type with hstore based
>> one, but add something json-like based on nested hstore instead.
>>
>> Maybe call it jsdoc or jdoc or jsobj or somesuch.
> This is exactly what needs to be done, full stop (how about: hstore).
hstore has completely different i/o formats and thus has similar
backwards compatibility problems.
> It really comes down to this: changing the serialization behaviors
It is really not "serialisation behaviours" as there is nothing you
can sensibly serialise to have repeated keys.

I agree that you can "generate" such JSON which would be valid
input tu any json parser, but no JavaScript Object which really serializes
to such JSON.
> that have been in production for 2 releases (three if you count the
> extension) is bad enough, but making impossible some legal json
> constructions which are currently possible is an unacceptable
> compatibility break.  
we should have disallowed this from the beginning and should
have encourages using text as storage for JavaScript source code.
> It's going to break applications I've currently
> put into production with no clear workaround.  
we could rename the old json type during pg_upgrade, but this
would likely break at least implicit casts in functions.
> This is quite frankly
> not ok and and I'm calling foul.  The RFC may claim that these
> constructions are dubious but that's irrelevant.  It's up to the
> parser to decide that and when serializing you are not in control of
> the parser.
You could choose a sane serializer ;)

The main argument here is still weather "json" is source
code or serialization result for JavaScript Object (Notation).

> Had the json type been stuffed into an extension, there would be a
> clearer path to get to where you want to go since we could have walled
> off the old functionality and introduced side by side API calls.  As
> things stand now, I don't see a clean path to do that.

>> 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.  
But one could argue that this is not "json" either but rather some
json-like input format for special parsers.

Current recommendation is to use "text" for these kinds of things.

>> 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.
All these would be possible if we redefined json as another notation
for XML instead of string representation of JavaScript Object :)

And things could really be "in-place" only inside pl/language functions,
as PostgreSQL is still MVCC.

What should be faster is access to nested values, though I suspect
that it is not significantly faster unless you have very large json
documents.

Cheers

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