On 11/14/2013 01:42 AM, Andrew Dunstan wrote: > > On 11/13/2013 07:01 PM, Hannu Krosing wrote: >> >> I guess we should not replace current JSON type with hstore based >> one, but add something json-like based on nested hstore instead. > > > Well, that's two voices for that course of action. I am not really "for" it (I would have liked to have a json_object/json_structure instead of json_string as the meaning of "json") but I think there is quite strong argument for not breaking backwards compatibility. > > Interesting that I don't think I heard a single voice for this either > at pgCon or pgOpen, I attended neither, but I did voice my preferences for _not_ having the "json-as-source-code" type on the mailing lists during previous json discussions.
> although I spent large amounts of time at both talking to people about > Json, so I'd be interested to hear more voices. > > It would actually simplify things in a way if we do that - we've been > working on > a way of doing this that wouldn't upset pg_upgrade. This would render > that effort unnecessary. I wonder how hard it would be to rename current json to json_source and have a new nested-hstore based json ? > > However it will complicate things for users who will have to choose > between the data types, > and function authors who will possibly have to write versions of > functions to work with both types. You mostly want the functions for json-object type. This is supported by the fact that current functions on json-source treat it as json-object (for example key lookup gives you the value of latest key and not a list of all matching key values). You may want some new functions on json-source (maybe json_source_enumerate_key_values(json, key)) but the current ones are really for json-object. -- 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
