Horton

Re: Support tab completion for upper character inputs in psql

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Cc: "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Japin Li <japinli@hotmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, "smithpb2250@gmail.com" <smithpb2250@gmail.com>, "david.zhang@highgo.ca" <david.zhang@highgo.ca>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2022-02-01T22:06:58Z
Lists: pgsql-hackers 
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> We could do something hacky like matching case only when there's
>>> no longer any matching object names, but that might be too magic.
>> I experimented with that, and it actually doesn't seem as weird
>> as I feared.  See if you like this ...

> That's a reasonable compromise, and the implementation is indeed less
> hacky than one might have feared.  Although I think putting the
> `num_keywords` variable before `num_other` would read better.

Hm... I renamed "num_other" to "num_query_other" instead.

> Going through the uses of COMPLETE_WITH(_SCHEMA)_QUERY_PLUS, I noticed a
> few that had the keywords in lower case, which is fixed in the attached
> patch (except the hardcoded data types, which aren't really keywords).

Yeah, my oversight.  Pushed.

			regards, tom lane

Commits

  1. Fix minor memory leaks in psql's tab completion.

  2. Further tweaks for psql's new tab-completion logic.

  3. Treat case of tab-completion keywords a bit more carefully.

  4. psql: improve tab-complete's handling of variant SQL names.

  5. Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings.

  6. Use a WaitLatch for vacuum/autovacuum sleeping