Re: [patch] Proposal for \rotate in psql

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: Greg Stark <stark(at)mit(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] Proposal for \rotate in psql
Date: 2015-11-04 23:37:39
Message-ID: CAFj8pRBVO3qROeTyAeDVZNT0d-zed_-uu=Fjt+fCsWBXuWigTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2015-11-05 0:07 GMT+01:00 Daniel Verite <daniel(at)manitou-mail(dot)org>:

> Pavel Stehule wrote:
>
> > I am looking on this last patch. I talked about the name of this command
> > with more people, and the name "rotate" is unhappy. The correct name for
> > this visualization technique is "crosstab" (see google "crosstab"). The
> > conflict with our extension is unhappy, but using "rotate" is more worst
> -
> > (see google "rotate"). The term "rotate" is used less time (related to
> > topic), and usually with zero informed people. More, in attached doc, the
> > word "crosstab" is pretty often used, and then the word "rotate" has not
> > sense.
>
> First, thanks for looking again at the patch and for your feedback.
>
> I note that you dislike and oppose the current name, as previously
> when that choice of name was discussed quite a bit.
> However I disagree that "rotate" doesn't make sense. On the semantics
> side, several people have expressed upthread that it was OK, as a
> plausible synonym for "pivot". If it's unencumbered by previous use
> in this context, then all the better, I'd say why not corner it for our
> own use?
> It's not as if we had to cling to others people choices for psql
> meta-commands.
>
>
If there is correct and commonly used name, then using any other word is
wrong. More, if this word can be associated with different semantic. I know
so some people uses the "rotate', but it has a minimal cost, if these
people doesn't know existing terminology. My opinion is pretty strong in
this topic, mainly if we have to fix this name forever. It isn't internal
name, but clearly visible name.

> Anyway that's just a name. It shall be changed eventually to
> whatever the consensus is, if one happens to emerge.
>
> > The important question is sorting output. The vertical header is
> > sorted by first appearance in result. The horizontal header is
> > sorted in ascending or descending order. This is unfriendly for
> > often use case - month names. This can be solved by third parameter
> > - sort function.
>
> Right, it's not possible currently to sort the horizontal header by
> something else than the values in it.
> I agree that it would be best to allow it if there's a reasonable way to
> implement it. I'm not sure about letting the user provide a function
> in argument.
> In the case of the month names example, the function
> f(monthname)=number-of-month may not exist. If the
> user has to create it beforehand, it feels a bit demanding
> for a display feature.
>
> I wonder if this ordering information could be instead deduced
> somehow from the non-pivoted resultset at a lower cost.
> I'll try to think more and experiment around this.
>

It can be nice. These names can be transformed to numbers, but it lost some
information value. From the ideas that I found, the sort function is less
ugly. I invite any proposals. On second hand - this is not major issue -
it is "nice to have" category - and can to help with user adoption of this
function - the time dimensions (dows, months) are usual.

Maybe more simple idea - using transform function - the data in non-pivoted
can be numbers - and some parameter can transform numbers to text used in
horizontal header. It can pretty simple for implementation.

Regards

Pavel

p.s. Although I have maybe unlikely comments - I like this feature. It can
help, and it can be really valuable and visible psql feature.

>
>
> Best regards,
> --
> Daniel Vérité
> PostgreSQL-powered mailer: http://www.manitou-mail.org
> Twitter: @DanielVerite
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2015-11-05 00:18:44 Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Previous Message Daniel Verite 2015-11-04 23:34:56 Re: [patch] Proposal for \rotate in psql