Re: proposal - patch: psql - sort_by_size

pá 12. 7. 2019 v 15:10 odesílatel Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
napsal:

>
> Hello Pavel,
>
> > rebased patch attached
>
> I prefer patches with a number rather than a date, if possible. For one
> thing, there may be several updates in one day.
>
> About this version (20180708, probably v3): applies cleanly, compiles,
> make check ok, doc build ok. No tests.
>
> It works for me on a few manual tests against a 11.4 server.
>
> Documentation: if you say "\d*+", then it already applies to \db+ and
> \dP+, so why listing them? Otherwise, state all commands or make it work
> on all commands that have a size?
>

\dT+ show sizes too, and there is a mix of values "1, 4, 8, 12, 24, var". I
don't think so sort by size there has sense

> About the text:
> - remove , before "sorts"
> - ... outputs by decreasing size, when size is displayed.
> - add: When size is not displayed, the output is sorted by names.
>

ok

>
> I still think that the object name should be kept as a secondary sort
> criterion, in case of size equality, so that the output is deterministic.
> Having plenty of objects of the same size out of alphabetical order looks
> very strange.
>
> I still do not like much the boolean approach. I understand that the name
> approach has been rejected, and I can understand why.
>
> I've been thinking about another more generic interface, that I'm putting
> here for discussion, I do not claim that it is a good idea. Probably could
> fall under "over engineering", but it might not be much harder to
> implement, and it solves a few potential problems.
>
> The idea is to add an option to \d commands, such as "\echo -n":
>
> \dt+ [-o 1d,2a] ...
>
> meaning do the \dt+, order by column 1 descending, column 2 ascending.
> With this there would be no need for a special variable nor other
> extensions to specify some ordering, whatever the user wishes.
>
> Maybe it could be "\dt+ [-o '1 DESC, 2 ASC'] ..." so that the string
> is roughly used as an ORDER BY specification by the query, but it would be
> longer to specify.
>

I have two objections - although I think so this functionality can coexists
with functionality implemented by this patch

1. You cannot use column number for sort by size, because this value is
prettified (use pg_size_pretty).

2. Because @1, then there is not simple solution for sort by size

3. This extension should be generic, and then it will be much bigger patch

> It also solves the issue that if someone wants another sorting order we
> would end with competing boolean variables such as SORT_BY_SIZE,
> SORT_BY_TYPE, SORT_BY_SCHEMA, which would be pretty unpractical. The
> boolean approach works for *one* sorting extension and breaks at the next
> extension.
>
> Also, the boolean does not say that it is a descending order. I could be
> interested in looking at the small tables.
>
> Another benefit for me is that I do not like much variables with side
> effects, whereas with an explicit syntax there would be no such thing, the
> user has what was asked for. Ok, psql is full of them, but I cannot say I
> like it for that.
>
> The approach could be extended to specify a limit, eg \dt -l 10 would
> add a LIMIT 10 on the query.
>

It is common problem - when you do some repeated task, then you want to do
quickly. But sometimes you would to do some specialized task, and then you
should to overwrite default setting easy.

Good system should to support both. But commands that allows
parametrization can be hard for learning, hard for use. There are lot of
users of "vim" or "emacs", but most users prefers "notepad".

All is about searching some compromise.

> Also, the implementation could be high enough so that the description
> handlers would not have to deal with it individually, it could return
> the query which would then be completed with SORT/LIMIT clauses before
> being executed, possibly with a default order if none is specified.
>

I don't think so your proposal is bad, and it is not in conflict with this
patch, but it

a) doesn't solve SORT BY SIZE problem
b) requires modification of parser of any related \command - so it will be
bigger and massive patch.

In this moment I prefer my simple implementation still. My patch is related
just for few describe commands. Your proposal should be really generic
(there is not a reason limit it just for reports with size)

Simple boolean design doesn't block any enhancing of future. The effect of
SORT_BY_SIZE variable can be overwritten by some specialized future option
used inside \command.

Regards

Pavel

>
> --
> Fabien.
>
>
>