Re: proposal - patch: psql - sort_by_size - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: proposal - patch: psql - sort_by_size
Date
Msg-id alpine.DEB.2.21.1906290901330.27352@lancre
Whole thread Raw
In response to proposal - patch: psql - sort_by_size  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: proposal - patch: psql - sort_by_size
List pgsql-hackers
Hello Pavel,

> \set SORT_BY_SIZE on
> \dt -- sorted by schema, name (size is not calculated and is not visible)
> \dt+ -- sorted by size

Patch applies cleanly, compiles, runs. "make check" ok. doc build ok.

There are no tests. Some infrastructure should be in place so that such 
features can be tested, eg so psql-specific TAP tests. ISTM that there was 
a patch submitted for that, but I cannot find it:-( Maybe it is combined 
with some other patch in the CF.

I agree that the simpler the better for such a feature.

ISTM that the fact that the option is ignored on \dt is a little bit 
annoying. It means that \dt and \dt+ would not show their results in the 
same order. I understand that the point is to avoid the cost of computing 
the sizes, but if the user asked for it, should it be done anyway?

I'm wondering whether it would make sense to have a slightly more generic 
interface allowing for more values, eg:

  \set DESCRIPTION_SORT "name"
  \set DESCRIPTION_SORT "size"

Well, possibly this is a bad idea, so it is really a question.


+   Setting this variable to <literal>on</literal> causes so results of
+   <literal>\d*</literal> commands will be sorted by size, when size
+   is displayed.

Maybe the simpler: "Setting this variable on sorts \d* outputs by size, 
when size is displayed."

ISTM that the documentation is more generic than reality. Does it work 
with \db+? It seems to work with \dm+.

On equality, ISTM it it should sort by name as a secondary criterion.

I tested a few cases, although not partitioned tables.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Juanjo Santamaria Flecha
Date:
Subject: Re: TM format can mix encodings in to_char()
Next
From: Thomas Munro
Date:
Subject: Re: Commitfest 2019-07, the first of five* for PostgreSQL 13