|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Daniel Verite <daniel(at)manitou-mail(dot)org>|
|Cc:||Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>|
|Subject:||Re: [patch] Proposal for \crosstabview in psql|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Daniel Verite wrote:
> > regression=# select * from pg_class \crosstabview relnatts
> > \crosstabview: missing second argument
> > regression-#
> Fixed. This was modelled after the behavior of:
> select 1 \badcommand
> but I've changed to mimic what happens with:
> select 1 \g /some/invalid/path
> the query buffer is not discarded by the error but the prompt
> is ready for a fresh new command.
Works for me.
> > * A few examples in docs. The psql manpage should have at least two new
> > examples showing the crosstab features, one with the simplest case you
> > can think of, and another one showing all the features.
> Added that in the EXAMPLES section at the very end of the manpage.
Ok. Seems a bit too short to me, and I don't like the fact that you
can't actually run it because you need to create the my_table
beforehand. I think it'd be better if you used a VALUES clause there,
so that the reader can cut'n paste into psql to start to play with the
> > * In the "if (cont.cells[idx] != NULL && cont.cells[idx] != '\0')"
> > block (line 497 in the attached), can't we do the same thing by using
> > psprintf?
> In that block, we can't pass a cell contents as a valist and be done with
> that cell, because duplicates of (col value,row value) may happen
> at any iteration of the upper loop over PQntuples(results). Any cell really
> may need reallocation unpredictably until that loop is done, whereas
> psprintf starts by allocating a new buffer unconditionally, so it doesn't
> look to me like it could help to simplify that block.
I don't know what you mean, but here's what I meant.
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Stephen Frost||2016-04-07 19:45:24||if (!superuser) checks|
|Previous Message||Tom Lane||2016-04-07 19:21:39||Re: Performance improvement for joins where outer side is unique|