On 11/14/2013 12:09 AM, Merlin Moncure wrote: > On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus <j...@agliodbs.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Ü -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
