RE: Support tab completion for upper character inputs in psql

From: "Tang, Haiying" <tanghy(dot)fnst(at)cn(dot)fujitsu(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Tang, Haiying" <tanghy(dot)fnst(at)cn(dot)fujitsu(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: RE: Support tab completion for upper character inputs in psql
Date: 2021-02-09 14:48:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

At Sun, 07 Feb 2021 13:55:00 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> This looks like you're trying to force case-insensitive behavior
> whether that is appropriate or not. Does not sound like a good idea.

I'm still confused about the APPROPRIATE behavior of tab completion.
It seems ALTER table/tablespace <name> SET/RESET is already case-insensitive.

For example
# alter tablespace dbspace set(e[tab]
# alter tablespace dbspace set(effective_io_concurrency

# alter tablespace dbspace set(E[tab]
# alter tablespace dbspace set(EFFECTIVE_IO_CONCURRENCY

The above behavior is exactly the same as what the patch(attached in the following message) did for SET/RESET etc.

If anyone can share me some cases which show inappropriate scenarios of forcing case-insensitive inputs in psql.
I'd be grateful for that.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Bashtanov 2021-02-09 15:25:19 [patch] bit XOR aggregate functions
Previous Message John Naylor 2021-02-09 14:46:41 Re: WIP: BRIN multi-range indexes