PATCH: psql tab completion for SELECT

Hi pgsql-hackers,

Here's a little draft patch to add *some* tab completion ability for
SELECT in psql. I have often missed the ability, especially with
invocations of utility functions.

It would be nice to be able to suggest column names from the relevant
tables in the query, but, as the SQL language puts the column list
before the FROM clause, we have to use columns from all tables; I'm
certainly not the first to be frustrated by this language feature, but
we can't do much about it.

What my patch does:

For a command line with the single word SELECT, column names and
function names will be used for completions of the next word.
Function names have a "(" suffix added, largely because it makes them
easier to distinguish in the completion list.

Only the first select-list item can be tab-completed; i.e. SELECT foo,
b<tab> won't find column bar.

Examples:

postgres=# select rel<tab>
relacl relchecks relhasindex
relhassubclass (etc.)

postgres=# select str<tab>
string_to_array( strip( strpos(

How it works:

The implementation uses a normal non-schema query, because columns
don't have schemas.

The eligible columns are normal, visible columns.

I have tried to filter out the various functions which aren't likely
to be directly used in queries.

The eligible functions are those which are:
- visible
- not aggregate or window functions
- not RI_FKey_* functions
- not support functions for types, aggregates, operators, languages,
casts, access methods.

Completions for FROM, WHERE, etc. still work, since the additional
completions are only used immediately after the single word SELECT.

Is this likely to be a useful addition to PostgreSQL?

If so, I'll try to get the patch to a good standard. I am not aiming
for complete support for the SELECT grammar, but just the low-hanging
fruit.

I'm not aware of existing tests for psql tab completion. But I ran
"make check" anyway, with no problems.

Some other questions about how it should be done:

- Are my criteria for the columns and function names appropriate?

- Should I try to use a SchemaQuery so that function schema names can be used?

- Should I try to support simple cases of multiple columns? (How?
We can use TailMatches1(",") but how do we tell we aren't into the
FROM-clause or later?)

- How do we make it work with older servers, e.g. those that predate
some of the newer columns used in the function criteria?

Cheers,
Edmund Horner