> On 19 May 2021, at 09:53, Michael Paquier <michael@paquier.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 https://vmware.com/
