Re: pgsql: Add basic TAP tests for psql's tab-completion logic.

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>, Christoph Berg <myon@debian.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-01-04T05:30:09Z
Lists: pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Jan 3, 2020 at 7:06 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> No. Also tried setting PG_COLOR="off" and CLICOLOR=0 -- that also
>> didn't help. (This was based on possibly-relevant vars that "env"
>> showed were set).

Yeah, that's not terribly surprising, because if I'm reading those
escape sequences correctly they're not about color.  They seem to be
just cursor movement and line clearing, according to [1].

What I'm mystified by is why your copy of libreadline is choosing to
do that, rather than just space over to where the word should be printed
which is what every other copy seems to be doing.  I have a fresh new
Debian installation at hand, with

$ dpkg -l | grep readline
ii  libreadline-dev:amd64                 7.0-5                                amd64        GNU readline and history libraries, development files
ii  libreadline5:amd64                    5.2+dfsg-3+b13                       amd64        GNU readline and history libraries, run-time libraries
ii  libreadline7:amd64                    7.0-5                                amd64        GNU readline and history libraries, run-time libraries
ii  readline-common                       7.0-5                                all          GNU readline and history libraries, common files

and I'm not seeing the failure on it, either with TERM=xterm
or with TERM=xterm-256color.  So what's the missing ingredient?

> Removing the single check_completion() test from 010_tab_completion.pl
> that actually fails on my system ("offer multiple table choices")
> fixes the problem for me -- everything else passes.
> I suppose that this means that the problem is in "offer multiple table
> choices" specifically.

I'd hate to conclude that we can't test any completion behavior that
involves offering a list.

If we can't coerce libreadline into being less avant-garde in its
screen management, I suppose we could write a regex to recognize
xterm escape sequences and ignore those.  But I'd be happier about
this if I could reproduce the behavior.  I don't like the feeling
that there's something going on here that I don't understand.

BTW, it seems somewhat likely that this is less about libreadline
than about its dependency libtinfo.  On my machine that's from

ii  libtinfo6:amd64                       6.1+20181013-2+deb10u2               amd64        shared low-level terminfo library for terminal handling

what about yours?

			regards, tom lane

[1] https://www.xfree86.org/current/ctlseqs.html



Commits

  1. Skip tab-completion tests if envar SKIP_READLINE_TESTS is defined.

  2. Minor style improvements for tab-completion test.

  3. Avoid reading ~/.inputrc in tab-completion test, and revert other changes.

  4. Don't try to force TERM to a fixed value in tab-completion test.

  5. In tab-completion test, print out the value of TERM before changing it.

  6. Make tab-completion tests more robust.

  7. Further fixes for tab-completion TAP tests.

  8. Add an ugly workaround for a bug in some recent libedit versions.

  9. Add basic TAP tests for psql's tab-completion logic.

  10. Fix running out of file descriptors for spill files.