Re: json api WIP patch - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: json api WIP patch
Date
Msg-id 511015D2.2000005@dunslane.net
Whole thread Raw
In response to Re: json api WIP patch  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: json api WIP patch  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Will Leinweber
Date:
Subject: Re: json api WIP patch
Next
From: Daniel Farina
Date:
Subject: Re: json api WIP patch