On 02/04/2013 02:59 PM, Merlin Moncure wrote:
> On Mon, Feb 4, 2013 at 12:07 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> On 02/04/2013 12:57 PM, Merlin Moncure wrote:
>>
>>> *) it's bad enough that we drift from sql naming conventions and all
>>> type manipulation functions (except in hstore) with type name.
>>> json_get etc. at least using operators allow avoiding some of that
>>> unnecessary verbosity. what's next: text_concatenate('foo', 'bar')?
>>>
>> This names aren't set in stone either. I've been expecting some bikeshedding
>> there, and I'm surprised there hasn't been more.
> Well -- heh (asked to bikeshed: joy!) -- I felt like my objections
> were noted and am more interested in getting said functionality out
> the door than splitting hairs over names. Type prefix issue is under
> the same umbrella as use of the -> operator, that is, *not
> specifically related to this patch, and not worth holding up this
> patch over*. In both cases it's essentially crying over spilt milk.
>
> My only remaining nit with the proposal is with json_unnest().
>
> SQL unnest() produces list of scalars regardless of dimensionality --
> json unnest unwraps one level only (contrast: pl/pgsql array 'slice').
> So I think 'json_array_each', or perhaps json_slice() is a better fit
> there.
>
how about json_array_elements()?
cheers
andrew