From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Christoph Berg <myon@debian.org>, Andres Freund <andres@anarazel.de>,
        Amit Kapila <amit.kapila16@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
In-reply-to: 
 <CA+TgmoZC_6z3d5+6n1GVfy898uoBHMPPJU4-nAQLG5ZkaEyqdQ@mail.gmail.com>
References: <E1in6ft-0004zR-6l@gemulon.postgresql.org>
 <20200103110128.GA28967@msg.df7cb.de> <13708.1578059577@sss.pgh.pa.us>
 <25771.1578249042@sss.pgh.pa.us> <20200106105608.GB18560@msg.df7cb.de>
 <3764.1578323719@sss.pgh.pa.us> <20200106191303.GA3975@msg.df7cb.de>
 <19973.1578351988@sss.pgh.pa.us> <28773.1578436137@sss.pgh.pa.us>
 <CA+TgmoZC_6z3d5+6n1GVfy898uoBHMPPJU4-nAQLG5ZkaEyqdQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 09 Jan 2020 09:45:20 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7490.1578584805.1@sss.pgh.pa.us>
Date: Thu, 09 Jan 2020 10:46:45 -0500
Message-ID: <7491.1578584805@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> The level of effort you've put into this is extremely impressive, but
> I can't shake the feeling that you're going to keep finding issues in
> the test setup, the operating system, or the upstream libraries,
> rather than bugs in PostgreSQL. Maybe this is all just one-time
> stabilization effort, but...

Yeah, this is pretty nearly what I feared would happen, given libedit's
apparently-well-earned evil reputation.  I suspect that the filename
completion tests I posted over in that thread may expose another round
of issues.  If we can get past that, I think that expanding our test
coverage for the rest of tab-complete.c should be relatively
unproblematic, because there aren't very many other readline behaviors
that tab-complete.c is depending on.

One alternative is to give up on the idea of ever having any test
coverage for tab-complete.c, which doesn't seem very desirable.

Or we could disable the tests when using libedit, or provide some
switch to make it easier for the user/packager to do so.

In Debian's case, I suspect that they don't care about the behavior
when using libedit, so skipping the test would be just fine for them.
What they really ought to test is what happens after they sub in
libreadline at runtime ... but I imagine that their dubious legal
theories about all this would prevent them from actually doing that
during the package build.

			regards, tom lane

PS:  Stepping back from the immediate problem, it's obviously better
for all concerned if libedit is usable with Postgres.  So if they're
willing to patch problems, which we've found out they are, then coping
with this stuff is a win in the long run.