Re: JSON Function Bike Shedding

2013/2/13 David E. Wheeler <david(at)justatheory(dot)com>:
> 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

"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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers