Re: tab-completion debug print

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
>> 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.

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

It seems to me this behavior would be completely unusable if it's not
redirected; I don't understand why you're even considering that as an
interesting option. libreadline is necessarily active when we're doing
this, and it will get very confused (or at least produce a very confused
display) if anything else is emitting text onto the active console line.
Maybe somebody who never makes any typing errors at all and doesn't really
need to see what they typed could use it like that, but I for one would
find it quite useless.

In fact, I was thinking of proposing that the output shouldn't go
to stderr in the first place. If you do it like that, then you're
also confusing this info with query error output, which does little
for usability either.

Speaking of query error output, it wouldn't be a bad thing if this
mode could show any errors from the tab-completion queries.
I suppose people look into the postmaster log for that right now;
but if this were all going to some separate log file, I'd vote for
showing the constructed queries and their results or errors.

regards, tom lane