Re: [patch] Proposal for \crosstabview in psql - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [patch] Proposal for \crosstabview in psql
Date
Msg-id CA+TgmoZ4yAduq9j8XTGRBh868JH2nj_NW_qgkXB32CeDsVTy0w@mail.gmail.com
Whole thread Raw
In response to Re: [patch] Proposal for \crosstabview in psql  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: [patch] Proposal for \crosstabview in psql
Re: [patch] Proposal for \crosstabview in psql
List pgsql-hackers
On Thu, Feb 18, 2016 at 9:23 AM, Daniel Verite <daniel@manitou-mail.org> wrote:
>         Dean Rasheed wrote:
>
>> 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.
>
> About the vertical sort, I agree on all your points.
> It's best to rely on ORDER BY for all the reasons mentioned,
> as opposed to a separate sort in a second step.
>
> But you're considering the case when a user is designing
> or adapting a query for the purpose of crosstab
> viewing. As mentioned in my previous reply (about the
> methods to achieve horizontal sort), that scenario is not really
> what motivates the feature in the first place.
>
> If removing that sort option is required to move forward
> with the patch because it's controversial, so be it,
> but overall I don't see this as a benefit for the end user,
> it's just an option.

Discussion on this patch seems to have died off.  I'm probably not
going to win any popularity contests for saying this, but I think we
should reject this patch.  I don't feel like this is really a psql
feature: it's a powerful data visualization tool which we're proposing
to jam into psql.  I don't think that's psql's purpose.  I also think
it's quite possible that there could be an unbounded number of
slightly different things that people want here, and if we take this
one and a couple more, the code for these individual features could
come to be larger than all of psql, even though probably 95% of psql
users would never use any of those.

Now, that having been said, if other people want this feature to go in
and are willing to do the work to get it in, I've said my piece and
won't complain further.  There are a couple of committers who have
taken positive interest in this thread, so that's good.  However,
there are also a couple of committers who have expressed doubts
similar to mine, so that's not so good.  But worse than either of
those things, there is no real agreement on what the overall design of
this feature should be.  Everybody wants something a little different,
for different reasons.  If we can't come to an agreement, more or less
immediately, on what to try to get into 9.6, then this can't go into
this release.  Whether it should go into a future release is a
question we can leave for another time.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: dblink: add polymorphic functions.
Next
From: Julien Rouhaud
Date:
Subject: Re: auto_explain sample rate