Re: JSON Function Bike Shedding

On Fri, Mar 22, 2013 at 8:58 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> On 03/22/2013 09:29 AM, Merlin Moncure wrote:
>>
>> On Mon, Mar 18, 2013 at 3:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>
>>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>>>
>>>> I've been sitting here for a while mulling none too happily over the
>>>> debate on the names for the proposed JSON extraction functions. I
>>>> haven't really been happy with any of the suggestions, much, not least
>>>> my own original function names which were really only intended as
>>>> placeholders. Last night in the still watches I decided I just couldn't
>>>> go with a function name as almost totally content-free as get(), or even
>>>> get_text(). And I don't think prepending "json_'" to the name helps much
>>>> either.
>>>
>>> Agreed.
>>>
>>>> Just concentrating to start with on those get() functions, in the simple
>>>> case we really don't need them at all. hstore has the "->" operator
>>>> without documenting the underlying function ("fetchval"). So maybe we
>>>> should just do that.
>>>
>>> Well, not documenting the underlying function does not relieve you from
>>> having to name it in a reasonably sane fashion. It still wouldn't do
>>> to call it "get()".
>>
>> How about 'fetch'. Or is that just skirting the content free aspect?
>> Agree that 'path' is out (as unnest is out due to unfortunate semantic
>> confusion). At the end of the day, 'get()' is simply referencing an
>> array (either associative or not). Most languages do this with an
>> operator, but I think fetch is pretty solid term.
>>
>>
>>>> * I'd be inclined to stick with json_array_length() and
>>>> json_object_keys() - I think they describe pretty well what they
>>>> do.
>>>> hstore's skeys() does more or less the same as json_object_keys(),
>>>> so we could use that if we want to be consistent. I don't think
>>>> it's
>>>> a terribly good name though.
>>>> * json_unnest() should certainly be renamed. Alternatives that come
>>>> to
>>>> mind are json_unfold() or json_elements() or json_array_elements().
>>>> * json_each(), json_each_as_text(), json_populate_record() and
>>>> json_populate_recordset() - to be consistent with hstore we could
>>>> remove the "json_". We probably should remove the "_as_ from
>>>> json_each_as_text().
>>>
>>> I don't particularly have a dog in this fight, but do we really want
>>> some of these to have a json_ prefix and others not?
>>
>> That's already baked in, because 9.2 json functions have prefix.
>
>
> I have finally decided my position on this. I think we have lots of good
> precedents for using type names in function names: array functions, xml
> functions and enum functions, for example. I think these are the precedents
> to follow, rather than hstore. Some people will be unhappy that this means
> more typing, but SQL is somewhat verbose anyway, and whatever we do will
> make someone unhappy :-)
>
>
>> I'm
>> still partial to json_unwrap for unnest, but out of Andrew's
>> suggestions I like json_elements the best. Like removing _as_.
>>
>
> OK. I can live with that.
>
> New version forthcoming soon.

Thanks for that! I'm super duper busy lately, but i'd still like to
bone up the docs a little bit, so if I can find the time I'd like to
squeeze some in before we lock in the beta if that's all right.

merlin