Re: jsonb and nested hstore - Mailing list pgsql-hackers

On 01/30/2014 01:03 PM, Hannu Krosing wrote:
> On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
>> On 01/30/2014 12:34 PM, Merlin Moncure wrote:
>>> On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan <andrew@dunslane.net>
>>> wrote:
>>>>>> Now, if we're agreed on that, I then also wonder if the 'as_text'
>>>>>> argument needs to exist at all for the populate functions except for
>>>>>> backwards compatibility on the json side (not jsonb).  For
>>>>>> non-complex
>>>>>> structures it does best effort casting anyways so the flag is moot.
>>>>>>
>>>>> Well, I could certainly look at making the populate_record{set} and
>>>>> to_record{set} logic handle types that are arrays or composites
>>>>> inside the
>>>>> record. It might not be terribly hard to do - not sure.


>>>> A quick analysis suggests that this is fixable with fairly minimal
>>>> disturbance in the jsonb case.
> As row_to_json() works with arbitrarily complex nested types (for
> example row having a field
> of type array of another (table)type containing arrays of third type) it
> would be really nice if
> you can get the result back into that row without too much hassle.
>
> and it should be ok to treat json as "source type" and require it to be
> translated to jsonb
> for more complex operations


Might be possible.

>>>> In the json case it would probably involve
>>>> reparsing the inner json. That's probably doable, because the
>>>> routines are
>>>> all reentrant, but not likely to be terribly efficient. It will also
>>>> be a
>>>> deal more work.
>>> Right.  Also the text json functions are already in the wild anyways
>>> -- that's not in the scope of this patch so if they need to be fixed
>>> that could be done later.
>>>
>>> ISTM then the right course of action is to point jsonb 'populate'
>>> variants at hstore implementation, not the text json one and remove
>>> the 'as text' argument.  Being able to ditch that argument is the main
>>> reason why I think this should be handled now (not forcing hstore
>>> dependency to handle complex json is gravy).
>>
>> We can't reference any hstore code in jsonb. There is no guarantee
>> that hstore will even be loaded.
>>
>> We'd have to move that code from hstore to jsonb_support.c and then
>> make hstore refer to it.
> Or just copy it and leave hstore alone - the code duplication is not
> terribly huge
> here and hstore might still want to develop independently.
>


We have gone to great deal of trouble to make jsonb and nested hstore 
more or less incarnations of the same thing. The new hstore relies 
heavily on the new jsonb. So what you're suggesting is the opposite of 
what's been developed these last months.

cheers

andrew