Re: strange CREATE INDEX tab completion cases - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: strange CREATE INDEX tab completion cases
Date
Msg-id CAB7nPqTqGgnbW1qTi=m5v4_cg=Pgy1f+F2gQ7kO7qpupVtUycA@mail.gmail.com
Whole thread Raw
In response to strange CREATE INDEX tab completion cases  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: strange CREATE INDEX tab completion cases
List pgsql-hackers
On Sat, Dec 12, 2015 at 11:17 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> These two tab completion pieces look strange to me:
>
>     /* If we have CREATE|UNIQUE INDEX <sth> CONCURRENTLY, then add "ON" */
>      else if ((pg_strcasecmp(prev3_wd, "INDEX") == 0 ||
>                pg_strcasecmp(prev2_wd, "INDEX") == 0) &&
>               pg_strcasecmp(prev_wd, "CONCURRENTLY") == 0)
>          COMPLETE_WITH_CONST("ON");
>      /* If we have CREATE|UNIQUE INDEX <sth>, then add "ON" or "CONCURRENTLY" */
>      else if ((pg_strcasecmp(prev3_wd, "CREATE") == 0 ||
>                pg_strcasecmp(prev3_wd, "UNIQUE") == 0) &&
>               pg_strcasecmp(prev2_wd, "INDEX") == 0)
>     {
>          static const char *const list_CREATE_INDEX[] =
>          {"CONCURRENTLY", "ON", NULL};
>
>          COMPLETE_WITH_LIST(list_CREATE_INDEX);
>      }
>
> They appear to support a syntax along the lines of
>
>     CREATE INDEX name CONCURRENTLY
>
> which is not the actual syntax.

Yep. That's visibly a bug introduced by this commit:
commit: 37ec19a15ce452ee94f32ebc3d6a9a45868e82fd
author: Itagaki Takahiro <itagaki.takahiro@gmail.com>
date: Wed, 17 Feb 2010 04:09:40 +0000
Support new syntax and improve handling of parentheses in psql tab-completion.

The current implementation is missing a correct completion in a couple
of cases, among them:
-- Should be only ON
=# create index asd
CONCURRENTLY  ON
-- should give list of table
=# create index CONCURRENTLY aaa on
-- Should give ON and list of existing indexes
=# create index concurrently

Please see the attached to address those things (and others) with
extra fixes for a couple of comments.
Regards,
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Next
From: Magnus Hagander
Date:
Subject: Re: pg_stat_replication log positions vs base backups