Re: JSON Function Bike Shedding

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'm
still partial to json_unwrap for unnest, but out of Andrew's
suggestions I like json_elements the best. Like removing _as_.

merlin