\h tab-completion

On Wed, Jan 25, 2017 at 9:03 AM, Stephen Frost <sfrost@snowman.net> wrote:

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!

I think the following change in tab-complete.c would do the trick.

-       else if (Matches1("ALTER"))
+       else if (TailMatches1("ALTER"))

postgres=# \h ALTER
AGGREGATE DOMAIN FUNCTION
MATERIALIZED VIEW RULE SYSTEM TYPE
COLLATION EVENT TRIGGER GROUP OPERATOR
SCHEMA TABLE USER
CONVERSION EXTENSION INDEX POLICY
SEQUENCE TABLESPACE USER MAPPING FOR
DATABASE FOREIGN DATA WRAPPER LANGUAGE
PUBLICATION SERVER TEXT SEARCH VIEW
DEFAULT PRIVILEGES FOREIGN TABLE LARGE OBJECT ROLE
SUBSCRIPTION TRIGGER

--
Thank you,

Beena Emerson

Have a Great Day!

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

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

On Wed, Jan 25, 2017 at 11:43 AM, Michael Paquier <michael.paquier@gmail.com

wrote:

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.

I feared the same.
I will check this.

--
Thank you,

Beena Emerson

Have a Great Day!

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

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

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

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

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

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

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

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

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

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

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

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

On 03/17/2017 12:01 AM, Peter Eisentraut wrote:

Committed with some tweaking.

Thanks!

Andreas

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