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 that's a done deal based on 'performance'. I'm clearly not the only one to have complained about this though. merln -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
