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. Links 1. https://www.postgresql.org/message-id/CAPpHfdvG%3DJR5kqmZx7KvTyVgtQePX0QJ09TO1y3sN73WOfJf1Q%40mail.gmail.com ------ Regards, Alexander Korotkov
