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

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.

cheers

andrew