Re: JSON Function Bike Shedding - Mailing list pgsql-hackers

On Fri, Mar 22, 2013 at 8:58 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 03/22/2013 09:29 AM, Merlin Moncure wrote:
>>
>> On Mon, Mar 18, 2013 at 3:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>
>>> Andrew Dunstan <andrew@dunslane.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