Re: JSON Function Bike Shedding

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()".

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

regards, tom lane