From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Added missing tab completion for alter subscription set option |
Date: | 2021-05-20 16:10:26 |
Message-ID: | 3690759.1621527026@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
vignesh C <vignesh21(at)gmail(dot)com> writes:
> On Tue, May 18, 2021 at 9:20 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Pyhalov | 2021-05-20 17:43:42 | Function scan FDW pushdown |
Previous Message | vignesh C | 2021-05-20 16:04:47 | Re: Added missing tab completion for alter subscription set option |