Re: tab-completion debug print

On Mon, Nov 26, 2018 at 12:23:16PM +0900, Kyotaro HORIGUCHI wrote:
> Thank you for the comments.
> 
> At Sun, 25 Nov 2018 01:17:27 +0100, David Fetter <david@fetter.org> wrote in <20181125001727.GM958@fetter.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).

We could wrap just about anywhere if needed. I found it relatively
easy to puzzle what was going on in my brief tests just by looking at
the potentially-long lines.

> >+    for (int i = 0; list && list[i]; ++i)
> 
> # Are we using C99 for-loop-variable-declarations?

I thought we were using all of it, but of course I can move it
outside.

> 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" -> ("")

That's certainly fixable.

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

Should it be?

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate