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 |
Message-ID: | 5f225addccc54478a6436b78423f21be@G08CNEXMBPEKD05.g08.fujitsu.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
https://www.postgresql.org/message-id/flat/a63cbd45e3884cf9b3961c2a6a95dcb7%40G08CNEXMBPEKD05.g08.fujitsu.local
If anyone can share me some cases which show inappropriate scenarios of forcing case-insensitive inputs in psql.
I'd be grateful for that.
Regards,
Tang
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 |