Re: psql: missing tab completions for COMMENT ON

On Sat, May 28, 2011 at 10:38 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> Hi all,
>
> psql's auto-complete support for COMMENT ON was missing support for a
> few object types:
>
> 1.) EXTENSION and PROCEDURAL LANGUAGE are now auto-complete candidates
> for COMMENT ON [TAB]. Lists of extensions and procedural languages
> should also be filled in when a user types
>  COMMENT ON EXTENSION [TAB]
>  COMMENT ON PROCEDURAL LANGUAGE [TAB]

I don't see much point in auto-completing COMMENT ON PROCEDURAL
LANGUAGE. We already complete COMMENT ON LANGUAGE. I agree with
adding EXTENSION (so done).

> 2.) This part of tab-complete.c looked like a spurious leftover:
>
> *************** psql_completion(char *text, int start, i
> *** 1580,1592 ****
>
>                COMPLETE_WITH_LIST(list_TRANS2);
>        }
>        else if ((pg_strcasecmp(prev4_wd, "COMMENT") == 0 &&
>                          pg_strcasecmp(prev3_wd, "ON") == 0) ||
>                         (pg_strcasecmp(prev6_wd, "COMMENT") == 0 &&
> !                         pg_strcasecmp(prev5_wd, "ON") == 0) ||
> !                        (pg_strcasecmp(prev5_wd, "ON") == 0 &&
> !                         pg_strcasecmp(prev4_wd, "TEXT") == 0 &&
> !                         pg_strcasecmp(prev3_wd, "SEARCH") == 0))
>                COMPLETE_WITH_CONST("IS");
>
> Since we want these choices to be filled in for COMMENT ON TEXT SEARCH [TAB]:
>        {"CONFIGURATION", "DICTIONARY", "PARSER", "TEMPLATE", NULL};
>
> which were already being handled correctly in an above block.

Hmm, yeah. But while I'm looking at it, I notice that this will
handle object-type names that are one word or three words, but not two
words. And we now have FOREIGN TABLE. Committed your change plus a
bit of additional hackery to address that issue.

> One piece that I gave up on trying to fix is the auto-completion for
> {OPERATOR, OPERATOR CLASS, OPERATOR FAMILY}, since getting it working
> correctly would be a real hassle. There's the trouble of whether to
> auto-complete operators for OPERATOR [TAB], or whether to fill in
> {CLASS, FAMILY} instead. Plus the auto-completes for 'USING
> index_method'.
>
> While wasting time on OPERATOR [TAB], I realized we're being a bit
> overeager with this bit:
>
>    else if ((pg_strcasecmp(prev4_wd, "COMMENT") == 0 &&
>              pg_strcasecmp(prev3_wd, "ON") == 0) ||
>             (pg_strcasecmp(prev6_wd, "COMMENT") == 0 &&
>              pg_strcasecmp(prev5_wd, "ON") == 0))
>        COMPLETE_WITH_CONST("IS");
>
> which will auto-complete e.g.
>  COMMENT ON AGGREGATE avg [TAB]
> with 'IS', when instead we'd want the possible argument types to avg,
> or nothing at all. Same deal with a few other object types, but it's
> probably not worth worrying about (at least, I'm not worrying about it
> at the moment).

The whole tab completion machinery is pretty much just throwing darts
while blindfolded, but the effort to replace it with something better
is so large that we just keep poking at it the way it is...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company