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>
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
In-reply-to: <22817.1578167447@sss.pgh.pa.us>
References: <20200103170226.GB32629@msg.df7cb.de>
 <26339.1578072930@sss.pgh.pa.us> <20200103174839.GD32629@msg.df7cb.de>
 <CA+TgmoZsPe_G1ssO6KVPqbMQHDEz=vHPQH1jxaSjpG_QxM7wUg@mail.gmail.com>
 <CAH2-WznPzfWHu8PQwv1Qjpf4wQVPaaWpoO5NunFz9zsYKB4uJA@mail.gmail.com>
 <22669.1578104202@sss.pgh.pa.us>
 <CAH2-WznyU3QxzRr12W_tJAzjwM9qd6bh_ZGx3Xupk3RqE1t72A@mail.gmail.com>
 <25298.1578106280@sss.pgh.pa.us>
 <CAH2-Wzkq4OELzn3yZvuqsPuso5JfSXdaD+yW=1VMz2YpXTBYxA@mail.gmail.com>
 <CAH2-Wzk3xfc53A0KZRe4Xu9TALRU=HSfSVZqx3jBuws08mG-ew@mail.gmail.com>
 <3055.1578115809@sss.pgh.pa.us>
 <CAH2-Wz=CtOruqXPd3naWXNiQ0WvLSFnCDYmSDWy0hKiLrppXDQ@mail.gmail.com>
 <8038.1578119995@sss.pgh.pa.us>
 <CAH2-Wz=f4B9+Ob-51-5z9G8a9LmztNpgo0YbKuTjxus3kFjpCg@mail.gmail.com>
 <9256.1578121229@sss.pgh.pa.us> <25739.1578161968@sss.pgh.pa.us>
 <CAH2-WzkHftVLq1BzbJyXtSD0nf7HC8pAa8UYZwvL4nkSOv1x1A@mail.gmail.com>
 <22817.1578167447@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 04 Jan 2020 14:50:47 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23180.1578167938.1@sss.pgh.pa.us>
Date: Sat, 04 Jan 2020 14:58:58 -0500
Message-ID: <23181.1578167938@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Seeing that you're also having issues with a stack involving
> libtinfo.so.5, here's my theory: libtinfo version 5 is brain-dead
> about whether it needs to issue cursor repositioning commands, and
> tends to do so even when the cursor is in the right place already.
> Version 6 fixed that, which is why we're not seeing these escape
> sequences on any of the libedit-using buildfarm critters.

Nope, the buildfarm just blew up that theory: Andres' critters are
failing in the wake of fac1c04fe, with symptoms exactly like those
of my franken-libedit build.  So newer libtinfo doesn't fix it.

What has to have broken those machines was the change to explicitly
force TERM to "xterm".  Now I'm wondering what their prevailing
setting was before that.  Maybe it was undef, or some absolutely
vanilla thing that prevents libtinfo from thinking it can use any
escape sequences at all.  I'm going to go find out, because if we
can use that behavior globally, it'd be a heck of a lot safer
solution than the path of dealing with escape sequences explicitly.

			regards, tom lane