Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

[Pavel Stehule]

Hi

2018-01-12 2:35 GMT+01:00 Thomas Munro :

> On Thu, Nov 2, 2017 at 12:44 AM, Pavel Stehule 
> wrote:
> > I am sending updated patch with some basic doc
>
> Hi Pavel,
>
> I am not sure what the status of this patch is, but FYI:
>
> startup.c: In function ‘main’:
> startup.c:284:3: error: too few arguments to function ‘listAllDbs’
>success = listAllDbs(NULL, false);
>^
> In file included from startup.c:21:0:
> describe.h:68:13: note: declared here
>  extern bool listAllDbs(const char *pattern, bool verbose, sortby_type
> sortby, bool sort_desc);
>  ^
>

There are no agreement about optimal form of this feature - so I'll remove
this patch from commitfest.

Regards

Pavel


>
> --
> Thomas Munro
> http://www.enterprisedb.com
>

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

[Thomas Munro]

On Thu, Nov 2, 2017 at 12:44 AM, Pavel Stehule  wrote:
> I am sending updated patch with some basic doc

Hi Pavel,

I am not sure what the status of this patch is, but FYI:

startup.c: In function ‘main’:
startup.c:284:3: error: too few arguments to function ‘listAllDbs’
   success = listAllDbs(NULL, false);
   ^
In file included from startup.c:21:0:
describe.h:68:13: note: declared here
 extern bool listAllDbs(const char *pattern, bool verbose, sortby_type
sortby, bool sort_desc);
 ^

-- 
Thomas Munro
http://www.enterprisedb.com

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

[Pavel Stehule]

2017-12-08 22:49 GMT+01:00 Alexander Korotkov :

> Hi!
>
> On Mon, Nov 27, 2017 at 10:18 PM, Pavel Stehule 
> wrote:
>
>> 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,
>>
>
> Yes, that's an inevitable shortcoming.  psql is not backend and can't
> perform all the required checks on its side...
>
> 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),
>>
>
> Oh, this is surprisingly hard problem which probably have only imperative
> solution...
>
> 3. What queries will contains size calculations? It is not cheap -
>> requires AccessShareLock
>>
>
> Sorry, I didn't understand this point.  Yes, size calculation requires
> locking, but that is already true for \dt+ and \l+.  Why this is
> disadvantage of proposed approach?
>

Because you don't know the filter and sort clause (it can be generic), you
don't know, if you should to calculate or not the size. Or there should be
rule, so filter, order must be limited to displayed columns.

Regards

Pavel




> --
> Alexander Korotkov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

[Michael Paquier]

On Tue, Nov 28, 2017 at 4:18 AM, Pavel Stehule  wrote:
> 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.

As the discussion is still going on, I am moving this patch to next CF.
-- 
Michael

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

[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.

--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

[Magnus Hagander]

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.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/