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 |
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/ |