Re: new json funcs - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: new json funcs
Date
Msg-id 52E69C48.4060108@dunslane.net
Whole thread Raw
In response to Re: new json funcs  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: new json funcs  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 01/27/2014 12:43 PM, Merlin Moncure wrote:
> On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 01/24/2014 12:59 PM, Andrew Dunstan wrote:
>>> On 01/24/2014 03:40 PM, Laurence Rowe wrote:
>>>> For consistency with the existing json functions (json_each,
>>>> json_each_text, etc.) it might be better to add separate
>>>> json_to_record_text and json_to_recordset_text functions in place of
>>>> the nested_as_text parameter to json_to_record and json_to_recordset.
>>>>
>>>>
>>> It wouldn't be consistent with json_populate_record() and
>>> json_populate_recordset(), the two closest relatives, however.
>>>
>>> And yes, I appreciate that we have not been 100% consistent. Community
>>> design can be a bit messy that way.
>> FWIW, I prefer the parameter to having differently named functions.
> +1.
>


Note that we can only do this when the result type stays the same. It 
does not for json_each/json_each_text or 
json_extract_path/json_extract_path_text, which is why we have different 
functions for those cases.

cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add %z support to elog/ereport?
Next
From: Simon Riggs
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe