Re: JSON Function Bike Shedding

On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <andrew@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
stilla 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
nicemnemonic for "array"? 
>
> Probably. I deliberately avoided @> because it's used elsewhere to mean "contains" and using it for something quite
differenthere 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

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
upcomingtalk on the subject.) 

I’ll be there, yo!

David