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
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? |