|From:||"Daniel Verite" <daniel(at)manitou-mail(dot)org>|
|To:||"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>|
|Cc:||"Greg Stark" <stark(at)mit(dot)edu>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [patch] Proposal for \rotate in psql|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Pavel Stehule wrote:
> postgres=# \crosstabview 4 +month label
> Maybe using optional int order column instead label is better - then you can
> do sort on client side
> so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol]
In the meantime I've followed a different idea: allowing the
vertical header to be sorted too, still server-side.
That's because to me, the first impulse for a user noticing that
it's not sorted vertically would be to write
\crosstabview +customer month
rather than figure out the
\crosstabview customer +month_number month_name
But both ways aren't even mutually exclusive. We could support
\crosstabview [+|-]colV[:labelV] [+|-]colH[:labelH]
it's more complicated to understand, but not harder to implement.
Also, a non-zero FETCH_COUNT is supported by this version of the patch,
if the first internal FETCH retrieves less than FETCH_COUNT rows.
Otherwise a specific error is emitted.
Also there are minor changes in arguments and callers following
recent code changes for \o
Trying to crosstab with 10k+ distinct values vertically, I've noticed
that the current code is too slow, spending too much time
sorting. I'm currently replacing its simple arrays of distinct values
with AVL binary trees, which I expect to be much more efficient for
PostgreSQL-powered mailer: http://www.manitou-mail.org
|Next Message||Daniel Verite||2015-12-14 22:15:14||Re: [patch] Proposal for \rotate in psql|
|Previous Message||Merlin Moncure||2015-12-14 21:57:22||Re: fix for readline terminal size problems when window is resized with open pager|