On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan <and...@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. 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).
People handling json as text would then invoke a ::jsonb cast trading
off performance for flexibility which is perfectly fine. If you
agree, perhaps we can HINT the error in certain places that return
"ERROR: cannot call json_populate_record on a nested object" that the
jsonb variant can be used as a workaround.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
