Hi Vik, thanks so much for the comments and the offer to review!
I kept a low profile after my first message as there was already a
commitfest in progress, but now I'm working on a V2 patch.
I will include aggregate and window functions as you suggest. And
I'll exclude trigger functions.
I'd like to exclude more if we could, because there are already over
1000 completions on an empty database. I had thought of filtering out
functions with an argument of type internal but couldn't figure out
how to interrogate the proargtypes oidvector in a nice way.
Regarding support for older versions, psql fails silently if a tab
completion query fails. We could just let it do this, which is what
happens with, for example, ALTER PUBLICATION against a 9.6 server. I
can't see any existing completions that check the server version --
but completions that don't work against older versions, like ALTER
PUBLICATION, also aren't useful for older versions. SELECT is a bit
different as it can be useful against older versions that don't have
the pg_aggregate.aggcombinefn that my query uses for filtering out
aggregation support functions.
There's also the small irritation that when a completion query fails,
it aborts the user's current transaction to provide an incentive for
handling older versions gracefully.
Regarding multiple columns, I have an idea that if we check that:
a) the last of any SELECT/WHERE/GROUP BY/etc.-level keyword is a
SELECT (i.e. that we're in the SELECT clause of the query), and
b) the last word was a comma (or ended in a comma).
we can then proffer the column/function completions.
There may be other completions that could benefit from such a check,
e.g. table names after a comma in the FROM clause, but I just want to
get SELECT working first.