Re: Bug fix for tab completion of ALTER TABLE ... VALIDATE CONSTRAINT ...

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug fix for tab completion of ALTER TABLE ... VALIDATE CONSTRAINT ...
Date: 2021-09-03 18:27:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 19 May 2021, at 09:53, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Tue, Apr 27, 2021 at 12:58:52PM +0300, Aleksander Alekseev wrote:
>> I've noticed there is no tab completion for ALTER TABLE xxx ADD. Here
>> is an alternative version of the patch that fixes this as well. Not
>> sure if this should be in the same commit though.
> - /* If we have ALTER TABLE <sth> DROP, provide COLUMN or CONSTRAINT */
> - else if (Matches("ALTER", "TABLE", MatchAny, "DROP"))
> + /* If we have ALTER TABLE <sth> ADD|DROP, provide COLUMN or CONSTRAINT */
> + else if (Matches("ALTER", "TABLE", MatchAny, "ADD|DROP"))
> Seems to me that the behavior to not complete with COLUMN or
> CONSTRAINT for ADD is intentional, as it is possible to specify a
> constraint or column name without the object type first. This
> introduces a inconsistent behavior with what we do for columns with
> ADD, for one. So a more consistent approach would be to list columns,
> constraints, COLUMN and CONSTRAINT in the list of options available
> after ADD.
> + else if (Matches("ALTER", "TABLE", MatchAny, "VALIDATE", "CONSTRAINT"))
> + {
> + completion_info_charp = prev3_wd;
> + COMPLETE_WITH_QUERY(Query_for_nonvalid_constraint_of_table);
> + }
> Specifying valid constraints is an authorized grammar, so it does not
> seem that bad to keep things as they are, either. I would leave that
> alone.

This has stalled being marked Waiting on Author since May, and reading the
above it sounds like marking it Returned with Feedback is the logical next step
(patch also no longer applies).

Daniel Gustafsson

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-09-03 19:34:24 Re: Postgres perl module namespace
Previous Message Justin Pryzby 2021-09-03 18:27:25 Re: pgsql: Set the volatility of the timestamptz version of date_bin() back