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 <da...@fetter.org> wrote in
> <20181125001727.gm...@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
