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Ü