From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Kirk Wolak <wolakk(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Getting PSQL in Windows to support TAB/Autocomplete via modified readline... |
Date: | 2022-11-24 01:28:29 |
Message-ID: | 3769352.1669253309@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2022-11-23 18:11:22 -0500, Tom Lane wrote:
>> Huh ... do you recall the details? Large as tab-complete is, it's
>> far smaller than gram.y:
> So It might just be that we need to split up that very long "else if" chain in
> psql_completion().
Could be, yeah. Related point: I've wondered for awhile how long that
chain can get before we start noticing performance issues on slower
machines. Even when the standard is just human reaction time, there's
a limit to how many cycles you can throw away. So I'd like to see it
refactored somehow to be a bit less stupid --- but I have a nagging
feeling that we'd end up building some special-purpose program generator,
which is something I've not wanted to do. OTOH, in the best of all
possible worlds such a tool might make it easier to add tab
completions?
(In the past I've fantasized about auto-generating tab completion
logic from the backend grammar, but I fear it's just fantasy.
The backend grammar isn't factored right, and too many of its names
don't have clear traceability to what-kind-of-object-is-that.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kirk Wolak | 2022-11-24 01:55:18 | Re: Getting PSQL in Windows to support TAB/Autocomplete via modified readline... |
Previous Message | Andres Freund | 2022-11-24 00:41:44 | Re: Getting PSQL in Windows to support TAB/Autocomplete via modified readline... |