Re: additional json functionality

On 11/14/2013 12:09 AM, Merlin Moncure wrote:
> On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should
>> require hstore to do things like build
>>> Also, json_object is pretty weird to me, I'm not sure I see the
>>> advantage of a new serialization format, and I don't agree with the
>>> statement "but it is the caller's reponsibility to ensure that keys
>>> are not repeated.".
>> This is pretty standard in the programming languages I know of which use
>> JSON.
>>
>>> I think the caller should have no such
>>> responsibility. Keys should be able to repeated.
>> Apparently your experience with using JSON in practice has been fairly
>> different from mine; the projects I work on, the JSON is being
>> constantly converted back and forth to hashes and dictionaries, which
>> means that ordering is not preserved and keys have to be unique (or
>> become unique within one conversion cycle). I think, based on the
>> language of the RFC and common practice, that it's completely valid for
>> us to require unique keys within JSON-manipulation routines.
> Common practice? The internet is littered with complaints about
> documents being spontaneously re-ordered and or de-duplicated in
> various stacks. Other stacks provide mechanisms for explicit key
> order handling (see here: http://docs.python.org/2/library/json.html).
> Why do you think they did 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. The current
> json serialization API handles that just fine and the hstore stuff
> coming down the pike will not.
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.

For some time I was also pretty perplexed by by some PostgreSQL JSON
type discussions where JSON was not really being a defined as
the the type constructed from its string representation, and even not
a string which results from serialising an existing javascript object,
but rather a source code, which can be parsed into a structured type.

So PostgreSQL "json" type is *not* a structured type like hstore is but
is really a string type with a few syntax checks.

Some of the json_* functions are then defined on top of this
"json-source" type which treat this source as if it were actual
structured type.

It is kind of defining an "int-notation" type, which acts like an integer
when added to another integer, but is required to also keep its original
representation:

select '1+1'::"int-notation" + 2;
==> 4
select '1+1'::"int-notation"
==> 1+1

> I guess that's a done deal based on
> 'performance'. I'm clearly not the only one to have complained about
> this though.
I am pretty sure we can not move to internal object representation and
preserve the current 'json source" behaviour.

this is why I recommend not replacing json, but rather adding another
built-in
for real structured type.

then you can keep using current json for the earlier-quoted uses of
"processing instructions" and do real data manipulation on jsdoc/jsobj type.

Also most of the current json functions should also be moved to work on
jsobj instead with explicit cast from json to jsobj

Cheers

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