|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: tab-completion debug print|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
At Tue, 27 Nov 2018 22:30:57 +0100, David Fetter <david(at)fetter(dot)org> wrote in <20181127213057(dot)GT958(at)fetter(dot)org>
> On Tue, Nov 27, 2018 at 03:54:55PM -0500, Tom Lane wrote:
> > David Fetter <david(at)fetter(dot)org> writes:
> > > Do we still want this as a compile-time option, or does it make more
> > > sense as a run-time option? I'm thinking that with \L, it might make
> > > sense as a run-time option.
> > This seems to me to be strictly a developer debugging feature.
> I would have thought so, but as our tab completion gets bigger--and
> it's been steadily doing that--we may find ourselves in a situation
> where it'd be handy to debug things in a production environment, with
> all the restrictions that implies.
I'm not sure how much it is wanted but it's easy to do. Using
psql variable doesn't seem to make sense since the debug print
(currently) requires session log file, which can be turned on
only at the startup time. '-g' option is available by 0003.
$ psql -gL ~/psql.log postgres
> Can we conceive of a circumstance where the check for -L/\L would be
> significant? I've seen people type pretty quickly, but not thus far
> fast enough to notice a cache miss.
We could switch completion_matches body as necessity using
function poniter, but we aren't so eager for speed here. It is at
most called every time entering tab.
NTT Open Source Software Center
|Next Message||Lætitia Avrot||2018-11-28 08:59:08||Markdown format output for psql, design notes|
|Previous Message||Tomas Vondra||2018-11-28 08:15:08||Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-ed data|