Hi
I've updated the patch to V7 based on the following comments.
On Friday, April 23, 2021 11:58 AM, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote
>All usages of pg_string_tolower don't need a copy.
>So don't we change the function to in-place converter?
Refer to your later discussion with Tom. Keep the code as it is.
> if (completion_info_charp)
>+ {
> e_info_charp = escape_string(completion_info_charp);
>+ if(e_info_charp[0] == '"')
>+ completion_case_sensitive = true;
>+ else
>+ {
>+ le_str = pg_string_tolower(e_info_charp);
>
>It seems right to lower completion_info_charp and ..2 but it is not
>right that change completion_case_sensitive here, which only affects
>the returned candidates.
Agreed, code " completion_case_sensitive = true;" removed.
>By the way COMP_KEYWORD_CASE suggests that *keywords* are completed
>following the setting. However, they are not keywords, but
>identifiers. And some people (including me) might dislike that
>keywords and identifiers follow the same setting. Specifically I
>sometimes want keywords to be upper-cased but identifiers (always) be
>lower-cased.
Changed my design based on your suggestion. Now the upper character inputs for identifiers will always turn to lower
case(regardlessCOMP_KEYWORD_CASE) which I think can be accepted by most of PG users.
Eg: SET BYT<tab> / SET Byt<tab>
output when apply V6 patch: SET BYTEA_OUTPUT
output when apply V7 patch: SET bytea_output
On Friday, April 23, 2021 12:26 PM, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote
>Oh, I accidentally found a doubious behsbior.
>
>=# alter table public.<tab>
>public.c1 public.d1 public."t" public.t public."tt"
>
>The "t" and "tt" are needlessly lower-cased.
Good catch. I didn’t think of schema stuff before.
Bug fixed. Add tap tests for this scenario.
Please let me know if you find more insufficient issue in the patch. Any further suggestion is very welcome.
Regards,
Tang