Re: psql: fix variable existence tab completion

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

In response to

Browse pgsql-hackers by date

  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