On 03/22/2013 09:29 AM, Merlin Moncure wrote:
On Mon, Mar 18, 2013 at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Andrew Dunstan <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
