RE: Support tab completion for upper character inputs in psql

tanghy.fnst@fujitsu.com <tanghy.fnst@fujitsu.com>

From: "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Japin Li <japinli@hotmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, "smithpb2250@gmail.com" <smithpb2250@gmail.com>, "david.zhang@highgo.ca" <david.zhang@highgo.ca>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2022-01-30T07:07:17Z
Lists: 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



Commits

  1. Fix minor memory leaks in psql's tab completion.

  2. Further tweaks for psql's new tab-completion logic.

  3. Treat case of tab-completion keywords a bit more carefully.

  4. psql: improve tab-complete's handling of variant SQL names.

  5. Make PQcancel use the PGconn's tcp_user_timeout and keepalives settings.

  6. Use a WaitLatch for vacuum/autovacuum sleeping