Re: Support tab completion for upper character inputs in psql - Mailing list pgsql-hackers
From | Kyotaro Horiguchi |
---|---|
Subject | Re: Support tab completion for upper character inputs in psql |
Date | |
Msg-id | 20210423.115812.900808736988307020.horikyota.ntt@gmail.com Whole thread Raw |
In response to | RE: Support tab completion for upper character inputs in psql ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>) |
Responses |
Re: Support tab completion for upper character inputs in psql
Re: Support tab completion for upper character inputs in psql RE: Support tab completion for upper character inputs in psql |
List | pgsql-hackers |
At Thu, 22 Apr 2021 12:43:42 +0000, "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com> wrote in > On Wednesday, April 21, 2021 1:24 PM, Peter Smith <smithpb2250@gmail.com> Wrot> >4. Memory not freed in multiple places? > oops. Memory free added. All usages of pg_string_tolower don't need a copy. So don't we change the function to in-place converter? > >6. byte_length == 0? > >The byte_length was not being checked before, so why is the check needed now? > > We need to make sure the empty input to be case sensitive as before(HEAD). > For example > CREATE TABLE onetab1 (f1 int); > update onetab1 SET [tab] > > Without the check of "byte_length == 0", pg_strdup_keyword_case will make the column name "f1" to be upper case "F1". > Namely, the output will be " update onetab1 SET F1" which is not so good. > > I added some tab tests for this empty input case, too. > > >7. test typo "ralation" > >8. test typo "case-insensitiveq" > Thanks, typo fixed. > > Any further comment is very welcome. 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. This change prevents the following operation from getting the expected completion candidates. =# create table "T" (a int) partition by range(a); =# create table c1 partition of "T" for values from (0) to (10); =# alter table "T" drop partition C<tab> Is there any reason for doing that? + if (byte_length == 0 || completion_case_sensitive) Is the condition "byte_length == 0 ||" right? This results in a maybe-unexpected behavior, =# \set COM_KEYWORD_CASE upper =# create table t (a int) partition by range(a); =# create table d1 partition of t for values from (0) to (10); =# alter table t drop partition <tab> This results in =# alter table t drop partition d1 I think we are expecting D1 as the result. 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. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
pgsql-hackers by date: