Pavel Stehule wrote:
> 2. Data column are not well aligned - numbers are aligned as text
Thanks for spotting that, it's fixed in the attached new iteration of
the patch.
> 3. When data are multiattribute - then merging together with space separator
> is not practical
>
> * important information is lost
> * same transformation can be done as expression, so this feature is
> useless
The primary use case is for queries with 3 output columns
(A,B,C) where A and B are dimensions and C is uniquely
determined by (A,B).
How columns 4 and above get displayed is not essential to the
feature, as it's somehow a degenerate case. As you note, it
could be avoided by the user limiting the query to 3 columns,
and providing whatever expression fits for the 3rd column.
Still if the query has > 3 columns, it has to be dealt with.
The choices I've considered:
a- Just error out.
b- Force the user to specify which single column should be taken
as the value. That would be an additional argument to the command,
or the fixed 3rd column in the invocation without arg.
c- Stack the values horizontally in the same cell with a separator.
As the query implies f(A,B)=(C,D,E) we display C D E in the cell
at coordinates (A,B). It's what it does currently.
[a] is not very user friendly.
[b] seems acceptable. It discards columns but the user decides which.
[c] is meant as a best effort at not discarding anything.
When [c] gives poor results, the next step from my point of view
would be for the user to rework the query, just like in the general case
when a query is not satisfying.
You're suggesting a [d] choice, subdividing the horizontal headers.
It seems to me like a pretty radical change, multiplying the number
of columns, and it has also the potential to give poor results visually.
Let's see if more feedback comes.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite