Re: tab-completion debug print

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: david(at)fetter(dot)org
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tab-completion debug print
Date: 2018-11-26 03:23:16
Message-ID: 20181126.122316.90290428.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you for the comments.

At Sun, 25 Nov 2018 01:17:27 +0100, David Fetter <david(at)fetter(dot)org> wrote in <20181125001727(dot)GM958(at)fetter(dot)org>
> On Fri, Nov 23, 2018 at 04:32:31PM -0500, Tom Lane wrote:
> > Hm. I can see the value of instrumenting tab-complete when you're trying
> > to debug why it did something, but this output format seems pretty terse
> > and unreadable. Can we get it to print the completion text as well?
> > I'm imagining something more like
> >
> > 1414: "er "
> > 1435: ""
> > 1435: "ab"
> > 1435: ""
> > 1431: ""
> >
> > Perhaps there's room as well to print the context that the match looked
> > at:
> >
> > 1414: "alt" -> "er "
> > 1435: "alter " -> ""
> > 1435: "alter t" -> "ab"
> >
> > etc.
> >
> > regards, tom lane
>
> Is this something along the lines of what you had in mind?

The reason for the minimal output was it won't disturb console so
much when stderr is not redirected. It could be richer if we
premise redirection. Since every debug line is followed by a
line-feed, we don't need the brackets. Since the result is a set
so Devid's proposal to enclose the set by parentheses looks nice.
Also, result can contain matches containing word breaks (or even
an empty string) so quoting make every candidate string more
distinctive.

Finally, the attached shows the following debugging output.

INPUT: alter u<tab>(ser)<tab> <tab>
OUTPUT:
1445: "u" -> ("user", "user", "user mapping for")
1445: "user" -> ("user", "user", "user mapping for")
3630: "" -> ("", "horiguti", "MAPPING FOR", "pg_execute_server_program", "pg_monitor", "pg_read_all_settings", "pg_read_all_stats", "pg_read_server_files", "pg_signal_backend", "pg_stat_scan_tables", "pg_write_server_files", "usr1", "usr2")

INPUT: create function <tab>
OUTPUT:
3635: "" -> ("", "pg_ndistinct_out", "path_recv", "int4eq", "spg_quad_picksplit", "tsvectorsend", "float8_var_pop", "opaque_in", "interval_le", "macaddr_cmp", "range_gt..(17272 chars)..nge_in")

Wouldn't be a problem with the long line since it is for
debugging purpose. Of course we can limit the length easily (by
number of elements).

>+ for (int i = 0; list && list[i]; ++i)

# Are we using C99 for-loop-variable-declarations?

An arguable change in this version is enclosing empty result
lists with brackets, since it is just an intermediate state for
us.

[1431: "sael" -> ()]
3655: "sael" -> ("")

Showing completion context makes things a bit bothersome, since
complete_from_variables needs to take additional two parameters.
It is already shown in console conversasion so I'm not sure it's
worth the trouble.

1872: (...table t1 alter [COn]) -> ("CONSTRAINT")

To be friendly with the CI, the second patch is attached as the
difference from the first patch.

Note: This is not registered in this CF.

- v3-0001-Psql-completion-debug-print-feature.patch
W/O context version

- v3-0002-Add-context-information-in-tab-completion-debug-prin.patch
W context version

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v3-0001-Psql-completion-debug-print-feature.patch text/x-patch 2.0 KB
v3-0002-Add-context-information-in-tab-completion-debug-prin.patch text/x-patch 4.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2018-11-26 04:19:11 Re: csv format for psql
Previous Message Michael Paquier 2018-11-26 02:51:25 Broken and rotten TAP tests in contrib/bloom/