2017-11-27 8:58 GMT+01:00 Alexander Korotkov :
> On Tue, Nov 14, 2017 at 3:26 PM, Magnus Hagander
> wrote:
>
>> On Mon, Nov 13, 2017 at 3:17 PM, Dean Rasheed
>> wrote:
>>
>>> On 28 October 2017 at 13:46, Pavel Stehule
>>> wrote:
>>> > 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?
>>> >
>>>
>>> I really hate that syntax. This is going to turn into an
>>> incomprehensible mess, and isn't easily extended to support other
>>> options.
>>>
>>
>> +1. While useful in itself, I think it's definitely a dangerous pattern
>> to go down, as it'll only get worse.
>>
>>
>> I agree with people who have said they would prefer this to be
>>> available as a per-command option rather than as a variable that you
>>> have to set, but it needs a clearer syntax. I actually like Stephen's
>>> idea of using a user-defined SQL snippet, because that's a familiar
>>> syntax to people, and it avoids adding an ever-increasing number of
>>> options to these commands. Instead, the syntax could simply be:
>>>
>>
>> +1 here as well. And anybody who is actually going to need this level of
>> control definitely will know SQL...
>>
>> And if one wants to save some "standard patterns", it should be doable to
>> save the pattern itself in a variable and then use it with something like
>> "\dt :mysort" and have it expand the normal way there.
>>
>
> +1
> I agree, that would look better, especially with "standard patterns" which
> could help with too long to type each time SQL snippets.
>
I though about this design more time. I see following disadvantages
1. we are not able to check all possible variants of extended query. If
there will be some custom error, then we will raise pretty ugly error
messages,
2. I don't thing so using "Size" as table size in human readable format and
"size" as table size in raw format is intuitive, but any change of "Size"
can introduce some (less probability compatibility issues),
3. What queries will contains size calculations? It is not cheap - requires
AccessShareLock
This proposal is first time, when we cannot to detect full semantic from
\xxx command. When user extend query correctly, then it is better than
before, when not it is worse than before.
Regards
Pavel
> ------
> Alexander Korotkov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
