Re: proposal - patch: psql - sort_by_size - Mailing list pgsql-hackers
| From | Pavel Stehule |
|---|---|
| Subject | Re: proposal - patch: psql - sort_by_size |
| Date | |
| Msg-id | CAFj8pRCj=f0Ac7+1O4HieFA2LuhqtgPxV8U4BLm_jJYky67OQg@mail.gmail.com Whole thread Raw |
| In response to | Re: proposal - patch: psql - sort_by_size (Fabien COELHO <coelho@cri.ensmp.fr>) |
| List | pgsql-hackers |
pá 12. 7. 2019 v 15:10 odesílatel Fabien COELHO <coelho@cri.ensmp.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.
pgsql-hackers by date: