On Thu, May 20, 2021 at 9:40 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> vignesh C <vignes...@gmail.com> writes:
> > On Tue, May 18, 2021 at 9:20 PM Alvaro Herrera <alvhe...@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.
In my opinion let's not make that change as part of this fix. I think
we can fix the existing problem with the existing way of just
including the options directly in the tab-complete client code because
the new design has an impact on the older versions and also could end
up in duplication like Tom Lane had pointed out. We can start a new
thread for this and try to get others' opinions on it.
Regards,
Vignesh
