RE: Support tab completion for upper character inputs in psql - Mailing list pgsql-hackers

From tanghy.fnst@fujitsu.com
Subject RE: Support tab completion for upper character inputs in psql
Date
Msg-id OS0PR01MB611316C146B24C6C156AE455FB249@OS0PR01MB6113.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Support tab completion for upper character inputs in psql  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Saturday, January 29, 2022 1:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com> writes:
> > I did some tests on it and here are something cases I feel we need to confirm
> > whether they are suitable.
>
> > 1) postgres=# create table atest(id int, "iD" int, "ID" int);
> > 2) CREATE TABLE
> > 3) postgres=# alter table atest rename i[TAB]
> > 4) id    "iD"
> > 5) postgres=# alter table atest rename I[TAB]
> > 6) id    "iD"
>
> > The tab completion for 5) ignored "ID", is that correct?
>
> Perhaps I misunderstood your original complaint, but what I thought
> you were unhappy about was that unquoted ID is a legal spelling of
> "id" and so I<TAB> ought to be willing to complete that.  These
> examples with case variants of the same word are of some interest,
> but people aren't really going to create tables with these sorts of
> names, so we shouldn't let them drive the design IMO.
>
> Anyway, the existing behavior for these examples is
>
> alter table atest rename i<TAB> --- completes immediately to id
> alter table atest rename I<TAB> --- offers nothing
>
> It's certainly arguable that the first case is right as-is and we
> shouldn't change it.  I think that could be handled by tweaking my
> patch so that it wouldn't offer completions that start with a quote
> unless the input word does.  That would also cause I<TAB> to complete
> immediately to id, which is arguably fine.
>
> > I think what we are trying to do is to ease the burden of typing double quote
> for user.
>
> I'm not thinking about it that way at all.  To me, the goal is to make
> tab completion do something sensible when presented with legal variant
> spellings of a word.  The two cases where it currently fails to do
> that are (1) unquoted input that needs to be downcased, and (2) input
> that is quoted when it doesn't strictly need to be.
>
> To the extent that we can supply a required quote that the user
> failed to type, that's fine, but it's not a primary goal of the patch.
> Examples like these make me question whether it's even something we
> want; it's resulting in extraneous matches that people might find more
> annoying than helpful.  Now I *think* that these aren't realistic
> cases and that in real cases adding quotes will be helpful more often
> than not, but it's debatable.
>
> > One the other hand, I'm not so comfortable with the output of "iD" in line
> 13.
> > If user doesn't type double quote, why we add double quote to the output?
>
> That's certainly a valid argument.
>
> > Could we make the output of 13) like below?
> > 12) postgres=# alter table atest rename i[TAB]
> > ??) id  iD
>
> That doesn't seem sensible at all.

Thanks for your kindly explanation.
I'm fine with the current tap completion style with your V16 patch.

Regards,
Tang



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: CREATEROLE and role ownership hierarchies
Next
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: Support tab completion for upper character inputs in psql