On 9/22/17 09:16, Pavel Stehule wrote: > Example: somebody set SORT_COLUMNS to schema_name value. This is > nonsense for \l command > > Now, I am thinking so more correct and practical design is based on > special mode, activated by variable > > PREFER_SIZE_SORT .. (off, asc, desc) > > This has sense for wide group of commands that can show size. And when > size is not visible, then this option is not active.
Maybe this shouldn't be a variable at all. It's not like you'll set this as a global preference. You probably want it for one command only. So a per-command option might make more sense.
Sure, I cannot to know, what users will do. But, when I need to see a size of objects, then I prefer the sort by size desc every time. If I need to find some object, then I can to use a searching in pager. So in my case, this settings will be in psqlrc. In GoodData we used years own customization - the order by size was hardcoded and nobody reported me any issue.
Alexander proposed some per command option, but current syntax of psql commands don't allows some simple parametrization. If it can be user friendly, then it should be short. From implementation perspective, it should be simply parsed. It should be intuitive too - too much symbols together is not good idea.
Maybe some prefix design - but it is not design for common people (although these people don't use psql usually)
'\sort size \dt ?
\dt:sort_by_size
\dt+:sort_by_size ?
I don't see any good design in this direction
I though about Alexander proposal, and I am thinking so it can be probably best if we respect psql design. I implemented two command suffixes (supported only when it has sense) "s" sorted by size and "d" as descent
so list of tables can be sorted with commands:
\dt+sd (in this case, the order is not strict), so command
\dtsd+ is working too (same \disd+ or \di+sd)
These two chars are acceptable. Same principle is used for \l command
\lsd+ or \l+sd
What do you think about it?
Regards
Pavel
Regards
Pavel
-- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services