2013/2/13 David E. Wheeler <da...@justatheory.com>: > On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <and...@dunslane.net> wrote: > >> I don't have any problem getting rid of the json_ prefixes, except for >> json_agg which I think should keep it (c.f. string_agg, array_agg). > > I think that's an unfortunately naming forced on us by the SQL standard, and > it doesn't mean we have to use it anyway. > >> I will take some of this under advisement. Note that json_populate_record's >> name was taken from hstore's populate_record, so if we're trying to use >> similar names then it should possibly be just populate_record. Or if that's >> still a bit long I would accept to_record. > > to_record()++ > >> I think Merlin's suggestion if unwrap might be good. Or simply "elements()" >> might work. > > Perhaps unwrap() returns a set and elements() returns an array? > >>> AS for #> and #>>, what about @> and @>> instead? Or am I just too much the >>> Perl hacker for thinking that @ is a nice mnemonic for "array"? >> >> Probably. I deliberately avoided @> because it's used elsewhere to mean >> "contains" and using it for something quite different here might be >> confusing. > > I can see that, especially if you end up adding exists(): @> could be its > operator. > >> I think this is beyond bikeshedding. Apparently you have missed the >> existence of json_object_keys(). > > Oh, I forgot it returned a set rather than an array. So I suggest: > > values() - Returns an array > keys() - Returns an array
"values" is keyword and "keys" is relative high risk too Regards Pavel > > And: > > unwrap() - Returns a set > skeys() - Returns a set > > Er, okay, so skeys() sucks alongside the others here. If we were to steal > from hstore, these would be: > > svals() - Returns a set > skeys() - Returns a set > avals() - Returns an array > akeys() - Returns an array > > I don’t love those, but if we want to follow precedent… > >> The new API makes many or all of these things possible to do with relative >> ease as extensions (See my possibly upcoming talk on the subject.) > > I’ll be there, yo! > > David > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
