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 |
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 |