[PATCH v1] Fix tab completion for DROP INDEX CONCURRENTLY

On Mon, Oct 19, 2026 at 12:03 PM Sho Ito <i.sho.0628@gmail.com> wrote:

The attached patch limits completion to `RESTRICT` for concurrent index
drops. Ordinary `DROP INDEX` continues to offer both `CASCADE` and `RESTRICT`.

Thanks for the patch! LGTM.

This patch should be backpatched to all supported versions?

Regards,

--
Fujii Masao

On Oct 19, 2026, at 11:02, Sho Ito <i.sho.0628@gmail.com> wrote:

Hi,

psql currently offers `CASCADE` after `DROP INDEX CONCURRENTLY <index_name>`,
although the backend rejects that combination [1].

The attached patch limits completion to `RESTRICT` for concurrent index
drops. Ordinary `DROP INDEX` continues to offer both `CASCADE` and `RESTRICT`.

[1] https://github.com/postgres/postgres/blob/3138f248cd3de43dd0f96760fc666152ea8a5c37/src/backend/commands/tablecmds.c#L1590-L1593

Kind regards,
Sho Ito

--
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Sho Ito (Sean)

E-mail: i.sho.0628@gmail.com
LinkedIn: https://www.linkedin.com/in/sho-ito-0628/
GitHub: https://github.com/sean0628/
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
<v1-0001-Fix-tab-completion-for-DROP-INDEX-CONCURRENTLY.patch>

Good catch.
```
evantest=# DROP INDEX CONCURRENTLY i
CASCADE RESTRICT
evantest=# DROP INDEX CONCURRENTLY i cascade;
ERROR: DROP INDEX CONCURRENTLY does not support CASCADE
```

The fix looks good to me. I also verified that it only removes “CASCADE” from “DROP INDEX CONCURRENTLY”, while “DROP INDEX” is not affected.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Hi Fujii-san,

This patch should be backpatched to all supported versions?

Yes, backpatching down to v14 sounds reasonable to me.
I can help prepare branch-specific patches if needed.

Thanks to you and Chao for reviewing the patch.

Kind regards,
Sho Ito

--
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
*Sho Ito (Sean)*

E-mail: i.sho.0628@gmail.com
LinkedIn: *https://www.linkedin.com/in/sho-ito-0628/
<https://www.linkedin.com/in/sho-ito-0628/&gt;*
GitHub: https://github.com/sean0628/
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

Hi Sho,

Thanks for the patch.

One small thing I noticed. With only RESTRICT left, Tab now fills it in
directly.
Since RESTRICT is the default, it may not help much, and
"DROP INDEX CONCURRENTLY IF " plus Tab becomes
"IF RESTRICT". Maybe we could just remove the rule?

Thanks,
Shihao

On Wed, Oct 21, 2026 at 9:21 AM shihao zhong <zhong950419@gmail.com> wrote:

Since RESTRICT is the default, it may not help much, and
"DROP INDEX CONCURRENTLY IF " plus Tab becomes
"IF RESTRICT". Maybe we could just remove the rule?

Hi Shihao,

Agreed. Since `RESTRICT` is the default, there is little benefit in offering
it here. I'll remove the rule in v2.

Thanks for the review!

Sho

--
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
*Sho Ito (Sean)*

E-mail: i.sho.0628@gmail.com
LinkedIn: *https://www.linkedin.com/in/sho-ito-0628/
<https://www.linkedin.com/in/sho-ito-0628/&gt;*
GitHub: https://github.com/sean0628/
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

On Wed, Oct 21, 2026 at 2:12 PM Sho Ito <i.sho.0628@gmail.com> wrote:

Agreed. Since `RESTRICT` is the default, there is little benefit in offering
it here.

We already offer completion for optional clauses that make the default explicit,
such as WITH after REFRESH MATERIALIZED VIEW CONCURRENTLY <name>.
So I think v1 is fine too.

Regards,

--
Fujii Masao

On Wed, Oct 21, 2026 at 4:15 PM Fujii Masao <masao.fujii@gmail.com> wrote:

We already offer completion for optional clauses that make the default
explicit,
such as WITH after REFRESH MATERIALIZED VIEW CONCURRENTLY <name>.
So I think v1 is fine too.

Hi Fujii-san,

Thanks, that makes sense. How about keeping v1 for now and addressing
the incorrect completion after `IF` separately by improving completion
for `IF EXISTS` in the affected `DROP` commands?

Shihao, would that work for you?

Regards,
Sho

--
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
*Sho Ito (Sean)*

E-mail: i.sho.0628@gmail.com
LinkedIn: *https://www.linkedin.com/in/sho-ito-0628/
<https://www.linkedin.com/in/sho-ito-0628/&gt;*
GitHub: https://github.com/sean0628/
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

On Wed, Oct 21, 2026 at 4:34 PM Sho Ito <i.sho.0628@gmail.com> wrote:

Thanks, that makes sense. How about keeping v1 for now

+1

and addressing
the incorrect completion after `IF` separately by improving completion
for `IF EXISTS` in the affected `DROP` commands?

IIUC, currently, psql does not offer tab completion for "IF EXISTS" or
"IF NOT EXISTS". But, are you suggesting adding support for these clauses
across commands? I'm not sure how much benefit this would provide
relative to the implementation effort.

BTW, since "if" is not a reserved keyword, an index can be named "if".
What should tab completion offer after "DROP INDEX CONCURRENTLY if"
in that case?

Regards,

--
Fujii Masao

On Wed, Oct 21, 2026 at 5:44 PM Fujii Masao <masao.fujii@gmail.com> wrote:

On Wed, Oct 21, 2026 at 4:34 PM Sho Ito <i.sho.0628@gmail.com> wrote:

Thanks, that makes sense. How about keeping v1 for now

+1

I've pushed v1. Thanks!

Regards,

--
Fujii Masao

Fujii Masao wrote:

BTW, since "if" is not a reserved keyword, an index can be named "if".
What should tab completion offer after "DROP INDEX CONCURRENTLY if"
in that case?

Hi Fujii-san,

You're right. I had the affected `DROP` commands in mind, but hadn't
considered an index named `if`. In that case, `RESTRICT` is a valid
completion, so calling the completion after `IF` incorrect was too broad.

I agree that broader `IF [NOT] EXISTS` support would need more thought,
and don't plan to pursue it for now.

Thanks for the review and for committing v1!

Regards,
Sho

--
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
*Sho Ito (Sean)*

E-mail: i.sho.0628@gmail.com
LinkedIn: *https://www.linkedin.com/in/sho-ito-0628/
<https://www.linkedin.com/in/sho-ito-0628/&gt;*
GitHub: https://github.com/sean0628/
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝