Re: tab-completion debug print

On Sun, Nov 25, 2018 at 11:21:51PM -0500, Tom Lane wrote:
> 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.

Integrating with libreadline would be a *much* bigger project for
reasons starting with the ones you state.

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

I briefly thought about logging this to the postmaster log, but psql
is not the server, and doesn't, as a rule, have access to the same
kinds of things the server does, so it's not really the right thing.
On a busy server, because we don't yet have ways to carve off streams
of logs, these ones could get lost in the noise.

This brings up an interesting idea, though. It seems like we're
backing into a logging facility for psql with this feature. How about
just sending stderr to some file(s) in /var/log/psql/ , or if we're
getting super fancy, to the syslog family?

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