On 15 February 2016 at 14:08, Daniel Verite <dan...@manitou-mail.org> wrote: > Dean Rasheed wrote: > >> My biggest problem is with the sorting, for all the reasons discussed >> above. There is absolutely no reason for \crosstabview to be >> re-sorting rows -- they should just be left in the original query >> result order > > Normal top-down display: > > select v,to_char(d,'Mon') as m, c from v_data order by d; > > v | m | c > ----+-----+----- > v2 | Jan | bar > v1 | Apr | foo > v1 | Jul | baz > v0 | Jul | qux > > At this point, it seems to me that it's perfectly reasonable for our user > to expect the possibility of sorting additionally by "v" , without > changing the query and without changing the order of the horizontal > header: > > \crosstabview +v m c > > v | Jan | Apr | Jul > ----+-----+-----+----- > v0 | | | qux > v1 | | foo | baz > v2 | bar | | >
I don't find that example particularly compelling. If I want to sort the rows coming out of a query, my first thought is always going to be to add/adjust the query's ORDER BY clause, not use some weird +/- psql syntax. The crux of the problem here is that in a pivoted query resultset SQL can be used to control the order of the rows or the columns, but not both at the same time. IMO it is more natural to use SQL to control the order of the rows. The columns are the result of the psql pivoting, so it's reasonable to control them via psql options. A couple of other points to bear in mind: The number of columns is always going to be quite limited (at most 1600, and usually far less than that), whereas the number of rows could be arbitrarily large. So sorting the rows client-side in the way that you are could get very inefficient, whereas that's not such a problem for the columns. The column values are non-NULL, so they require a more limited set of sort options, whereas the rows could be anything, and people will want all the sort options to be available. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers