RE: Support tab completion for upper character inputs in psql

From: "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: "smithpb2250(at)gmail(dot)com" <smithpb2250(at)gmail(dot)com>, "david(dot)zhang(at)highgo(dot)ca" <david(dot)zhang(at)highgo(dot)ca>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Support tab completion for upper character inputs in psql
Date: 2021-09-10 13:50:31
Message-ID: OS0PR01MB61137C7B2B09C0431415B9DBFBD69@OS0PR01MB6113.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday, September 7, 2021 5:25 PM, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>The coding of valid_input_text() seems a bit bulky. I think you can do
>the same thing using strspn() without a loop.

Thanks, modified in V9 patch.

>The name is also not great. It's not like other strings are not "valid".

Modified.
valid_input_text() renamed to check_input_text()

>There is also no explanation why that specific set of characters is
>allowed and not others. Does it have something to do with identifier
>syntax? This needs to be explained.

Added some comments for pg_string_tolower_if_ascii().
For language like German/Turkish, it's not a good idea to lower the input text
because the upper case words may not retain the same meaning.(Pointed at [1~3])

>Seeing that valid_input_text() is always called together with
>pg_string_tolower(), I think those could be combined into one function,
>like pg_string_tolower_if_ascii() is whatever. That would save a lot of
>repetition.

Modified.

>There are a couple of queries where the result is *not*
>case-insensitive, namely
>
>Query_for_list_of_enum_values
>Query_for_list_of_available_extension_versions
>
>(and their variants). These are cases where the query result is not
>used as an identifier but as a (single-quoted) string. So that needs to
>be handled somehow, perhaps by adding a COMPLETE_WITH_QUERY_CS() similar
>to COMPLETE_WITH_CS().

Hmm, I think 'a (single-quoted) string' identifier behaves the same way with or without my patch.
Could your please give me an example on that?(to help me figure out why we need something like COMPLETE_WITH_QUERY_CS())

>(A test case for the enum case should be doable easily.)

Test added.

BTW, I found tap completion for enum value is not perfect on HEAD.
Maybe I will fix this problem in another thread.

example:
=# create type pp_colors as enum ('green', 'blue', 'black');
=# ALTER TYPE pp_colors RENAME VALUE 'b[tab]
=# alter type pp_colors rename value 'b' <- blue is not auto completed as expected

[1] https://www.postgresql.org/message-id/1282887.1619151455%40sss.pgh.pa.us
[2] https://www.postgresql.org/message-id/20210423.144443.2058612313278551429.horikyota.ntt%40gmail.com
[3] https://www.postgresql.org/message-id/a75a6574c0e3d4773ba20a73d493c2c9983c0657.camel%40cybertec.at

Regards,
Tang

Attachment Content-Type Size
v9-0001-Support-tab-completion-with-a-query-result-for-up.patch application/octet-stream 7.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-09-10 14:03:36 Re: a misbehavior of partition row movement (?)
Previous Message Robert Haas 2021-09-10 13:13:36 Re: parallelizing the archiver