Thread: [HACKERS] \h tab-completion

All,

I'm not really inclined to do it myself right now, but it'd be awful
nice if we had better table completion for \h.

Right now, '\h alter<tab>' returns nothing, and '\h alter' returns a
*bunch* of stuff.

Yet, we happily support '\h alter view' and friends, returning just the
info relevant for that particular command.

This would be a good starter project for someone new to work on, imv,
tho it could also go on the to-do list.

Thanks!

Stephen

On Wed, Jan 25, 2017 at 3:03 PM, Beena Emerson <memissemerson@gmail.com> wrote:
> I think the following change in tab-complete.c would do the trick.
>
> -       else if (Matches1("ALTER"))
> +       else if (TailMatches1("ALTER"))

Nope. This change breaks a bunch of subcommands, take for example
ALTER TABLE foo ALTER, which would be completed to all the potential
objects of ALTER commands with your patch, but in this case for
example we just need to look at the column names, CONSTRAINT and
COLUMN. CREATE is not part of any subcommands so that's easy to see it
work with \h. What I think you should do is making the code path of
\\h smarter with some exceptions by using TailMatchesCS2() for ALTER.
There is as well the case of DROP commands that should be treated by
the way.
-- 
Michael

On 01/25/2017 07:13 AM, Michael Paquier wrote:
> What I think you should do is making the code path of
> \\h smarter with some exceptions by using TailMatchesCS2() for ALTER.
> There is as well the case of DROP commands that should be treated by
> the way.

Yes, I think that is correct approach. I have attached a patch where I 
add completion for \h ALTER and \h DROP.

Andreas


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2/3/17 07:12, Andreas Karlsson wrote:
> On 01/25/2017 07:13 AM, Michael Paquier wrote:
>> What I think you should do is making the code path of
>> \\h smarter with some exceptions by using TailMatchesCS2() for ALTER.
>> There is as well the case of DROP commands that should be treated by
>> the way.
> 
> Yes, I think that is correct approach. I have attached a patch where I 
> add completion for \h ALTER and \h DROP.

Instead of creating another copy of list_ALTER, let's use the
words_after_create list and write a version of
create_command_generator/drop_command_generator.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hello,

At Wed, 1 Mar 2017 08:47:15 -0500, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote in
<ceaf1188-5d7d-a8e1-19aa-8184b5923072@2ndquadrant.com>
> On 2/3/17 07:12, Andreas Karlsson wrote:
> > On 01/25/2017 07:13 AM, Michael Paquier wrote:
> >> What I think you should do is making the code path of
> >> \\h smarter with some exceptions by using TailMatchesCS2() for ALTER.
> >> There is as well the case of DROP commands that should be treated by
> >> the way.
> > 
> > Yes, I think that is correct approach. I have attached a patch where I 
> > add completion for \h ALTER and \h DROP.
> 
> Instead of creating another copy of list_ALTER, let's use the
> words_after_create list and write a version of
> create_command_generator/drop_command_generator.

I'd like to separate the completion code into context-detector
and completion-engine. The former returns a "perse context value"
and the latter shows the suggestions from the values. Help engine
can use the same context-detector with the completion code. But
the correspondence between the two routines seems hardly
maintained:( (and such separation(refactoring) will be stuck on
the way)


Even this is a bit different topic from this patch aims, another
random thought on the help is that \h command should offer the
restriction words instead of all documents of possiblly-matching
(or head-matching) commands. For example, the current \h command
shows the following for create command.

=# \h create<cr>
Command:     CREATE ACCESS METHOD
Description: define a new access method
Syntax:
CREATE ACCESS METHOD name   TYPE access_method_type   HANDLER handler_function

Command:     CREATE AGGREGATE
...

This seems pointless to me and should offer the list of the next
words and short summary. gdb does the following for the case the
following.

| (gdb) help enable 
| Enable some breakpoints.
| Give breakpoint numbers (separated by spaces) as arguments.
| With no subcommand, breakpoints are enabled until you command otherwise.
| This is used to cancel the effect of the "disable" command.
| With a subcommand you can enable temporarily.
| 
| List of enable subcommands:
| 
| enable breakpoints -- Enable some breakpoints
| enable count -- Enable breakpoints for COUNT hits
| enable delete -- Enable breakpoints and delete when hit

| =# \h create<cr>
| Define an object
| 
| List of create subcommands:
| 
| CREATE ACCESS METHOD - Define a new access method
| CREATE AGGREGATE  - Define a new aggregate function
| ...


One bothersome problem is distinction between "CREATE TABLE" and
("CREATE TABLE AS" and "CREATE TABLESPACE"), but this might be
resolved by a small craft in documentation.

| - Documentation for "CREATE TABLE"
| Define a table
| 
| You might want to see the following commands.
| CREATE TABLE AS - Define a new table from the result of a query
| CREATE TABLESPACE - Define a new tablespace.
| 
| Syntax:
|  CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] %s ( [

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Hi Andreas,

On 3/1/17 8:47 AM, Peter Eisentraut wrote:
> On 2/3/17 07:12, Andreas Karlsson wrote:
>> On 01/25/2017 07:13 AM, Michael Paquier wrote:
>>> What I think you should do is making the code path of
>>> \\h smarter with some exceptions by using TailMatchesCS2() for ALTER.
>>> There is as well the case of DROP commands that should be treated by
>>> the way.
>>
>> Yes, I think that is correct approach. I have attached a patch where I 
>> add completion for \h ALTER and \h DROP.
> 
> Instead of creating another copy of list_ALTER, let's use the
> words_after_create list and write a version of
> create_command_generator/drop_command_generator.

Do you know when you will have a new patch available for review that
incorporates Peter's request?

Thanks,
-- 
-David
david@pgmasters.net

On 03/13/2017 03:56 PM, David Steele wrote:
> Do you know when you will have a new patch available for review that
> incorporates Peter's request?

I believe I will find the time to finish it some time in a couple of days.

Andreas

On 03/01/2017 02:47 PM, Peter Eisentraut wrote:
> Instead of creating another copy of list_ALTER, let's use the
> words_after_create list and write a version of
> create_command_generator/drop_command_generator.

Good idea. Here is a patch with that.

Andreas


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 3/15/17 22:46, Andreas Karlsson wrote:
> On 03/01/2017 02:47 PM, Peter Eisentraut wrote:
>> Instead of creating another copy of list_ALTER, let's use the
>> words_after_create list and write a version of
>> create_command_generator/drop_command_generator.
> 
> Good idea. Here is a patch with that.

Committed with some tweaking.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 03/17/2017 12:01 AM, Peter Eisentraut wrote:
> Committed with some tweaking.

Thanks!

Andreas