On Mon, Jun 14, 2021 at 4:14 PM Alexander Korotkov <aekorot...@gmail.com> wrote: > On Mon, Jun 14, 2021 at 3:50 PM Jonathan S. Katz <jk...@postgresql.org> wrote: > > On 6/13/21 5:18 PM, Alexander Korotkov wrote: > > > > >> "Expands an array into a set of rows. The array's elements are read out > > >> in storage order." > > >> > > >> If we tweaked the multirange "unnest" function, we could change it to: > > >> > > >> + <para> > > >> + Expands a multirange into a set of rows. > > >> + The ranges are read out in storage order (ascending). > > >> + </para> > > >> > > >> to match what the array "unnest" function docs, or > > >> > > >> + <para> > > >> + Expands a multirange into a set of rows that each > > >> + contain an individual range. > > >> + The ranges are read out in storage order (ascending). > > >> + </para> > > >> > > >> to be a bit more specific. However, I think this is also bordering on > > >> overengineering the text, given there has been a lack of feedback on the > > >> "unnest" array function description being confusing. > > > > > > I think it's not necessarily to say about rows here. Our > > > documentation already has already a number of examples, where we > > > describe set of returned values without speaking about rows including: > > > json_array_elements, json_array_elements_text, json_object_keys, > > > pg_listening_channels, pg_tablespace_databases... > > > > I do agree -- my main point was that I don't think we need to change > > anything. I proposed alternatives just to show some other ways of > > looking at it. But as I mentioned, at this point I think it's > > overengineering the text. > > > > If folks are good with the method + code, I think this is ready. > > Cool, thank you for the summary. I'll wait for two days since I've > published the last revision of the patch [1] (comes tomorrow), and > push it if no new issues arise.
Pushed! Thanks to thread participants for raising this topic and review. I'll be around to resolve issues if any. ------ Regards, Alexander Korotkov
