Re: Bug fix for tab completion of ALTER TABLE ... VALIDATE CONSTRAINT ...
От | Michael Paquier |
---|---|
Тема | Re: Bug fix for tab completion of ALTER TABLE ... VALIDATE CONSTRAINT ... |
Дата | |
Msg-id | YKTD7p/2GeQieThH@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Bug fix for tab completion of ALTER TABLE ... VALIDATE CONSTRAINT ... (Aleksander Alekseev <aleksander@timescale.com>) |
Ответы |
Re: Bug fix for tab completion of ALTER TABLE ... VALIDATE CONSTRAINT ...
|
Список | pgsql-hackers |
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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: