Re: json api WIP patch
От | Andrew Dunstan |
---|---|
Тема | Re: json api WIP patch |
Дата | |
Msg-id | 511015D2.2000005@dunslane.net обсуждение исходный текст |
Ответ на | Re: json api WIP patch (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: json api WIP patch
|
Список | 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 по дате отправления: