Re: new json funcs

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: new json funcs
Date: 2014-01-27 17:50:00
Message-ID: 52E69C48.4060108@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 01/27/2014 12:43 PM, Merlin Moncure wrote:
> On Fri, Jan 24, 2014 at 3:26 PM, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2014-01-27 17:58:02 Re: ALTER TABLE lock strength reduction patch is unsafe
Previous Message Tom Lane 2014-01-27 17:49:49 Re: Add %z support to elog/ereport?