From: | "Anton A(dot) Melnikov" <a(dot)melnikov(at)postgrespro(dot)ru> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Erik Wienhold <ewie(at)ewie(dot)name>, Steve Chavez <steve(at)supabase(dot)io>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql: fix variable existence tab completion |
Date: | 2024-05-07 07:37:27 |
Message-ID: | 836a0c2c-b4fe-4efb-bf86-b6b3271bedfe@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, Alexander!
On 06.05.2024 13:19, Alexander Korotkov wrote:
>> The patch attached fix the 010_tab_completion.pl test in the same way like [1].
>
> Thank you for the fix. As I get, the fix teaches
> 010_tab_completion.pl to tolerate the invalid result of tab
> completion. Do you think we could fix it another way to make the
> result of tab completion correct?
Right now i don't see any straight way to fix this to the correct tab completion.
There are several similar cases in this test.
E.g., for such a commands:
CREATE TABLE "mixedName" (f1 int, f2 text);
select * from "mi<TAB> ;
gives with debian 10:
postgres=# select * from \"mixedName\" ;
resulting in an error.
Now there is a similar workaround in the 010_tab_completion.pl with regex: qr/"mixedName\\?" /
I think if there were or will be complaints from users about this behavior in Debian 10,
then it makes sense to look for more complex solutions that will fix a backslash substitutions.
If no such complaints, then it is better to make a workaround in test.
With the best wishes,
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Wartak | 2024-05-07 07:43:36 | Re: elog/ereport VS misleading backtrace_function function address |
Previous Message | Michael Paquier | 2024-05-07 06:01:46 | Re: Use pgstat_kind_infos to read fixed shared stats structs |