Re: Added missing tab completion for alter subscription set option - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Added missing tab completion for alter subscription set option
Date
Msg-id 3690759.1621527026@sss.pgh.pa.us
Whole thread Raw
In response to Re: Added missing tab completion for alter subscription set option  (vignesh C <vignesh21@gmail.com>)
Responses Re: Added missing tab completion for alter subscription set option
List pgsql-hackers
vignesh C <vignesh21@gmail.com> writes:
> On Tue, May 18, 2021 at 9:20 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> I wish we didn't have to keep knowledge in the psql source on which
>> option names are to be used for each command.  If we had some function
>> SELECT pg_completion_options('alter subscription set');
>> that returned the list of options usable for each command, we wouldn't
>> have to ... psql would just retrieve the list of options for the current
>> command.

> On further analysis, I felt that as psql is a front end client, we
> should not put any dependency on backend code. I felt that might be
> the reason it has been coded to mention the options directly  in
> tab-complete instead of having any dependency on backend code.

Well, the problem with Alvaro's proposal is how do you square it
with psql's need to support back versions of the server.  Maybe
you could code tab-complete.c like "if server >= v15 then do X
else do Y", but since Y would be largely duplicative of the
server-side knowledge accessed by X, you haven't really gotten
rid of the two-places-that-know-this issue.  And I'm afraid that
tab-complete.c would become even more of a mess than it is now;
although maybe somebody can see a cute way to avoid that.

            regards, tom lane



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Added missing tab completion for alter subscription set option
Next
From: Alexander Pyhalov
Date:
Subject: Function scan FDW pushdown