Re: JSON Function Bike Shedding

On Feb 13, 2013, at 8:36 AM, Andrew Dunstan <andrew(at)dunslane(dot)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

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