Christoph Berg <myon@debian.org> writes:
> Re: Tom Lane 2020-01-02 <E1in6ft-0004zR-6l@gemulon.postgresql.org>
>> Add basic TAP tests for psql's tab-completion logic.
> The \DRD test fails on Debian/unstable:
Indeed. It appears that recent libedit breaks tab-completion for
words involving a backslash, which is the fault of this upstream
commit:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/filecomplete.c.diff?r1=1.52&r2=1.53
Basically what that's doing is applying de-backslashing to EVERY
word that completion is attempted on, whether it might be a filename
or not. So what psql_complete sees in this test case is just "DRD"
which of course it does not recognize as a possible psql backslash
command.
I found out while investigating this that the libedit version shipping
with buster (3.1-20181209) is differently broken for the same case:
instead of inapproriate forced de-escaping of the input of the
application-specific completion function, it applies inapproriate
forced escaping to the output of said function, so that when we see
"\DRD" and return "\drds", what comes out to the user is "\\drds".
libedit apparently needs a regression test suite even worse than we do.
I was kind of despairing of fixing this last night, but in the light
of morning it occurs to me that there's a possible workaround for the
de-escape bug: we could make psql_completion ignore the passed "text"
string and look at the original input buffer, as
get_previous_words() is already doing. I don't see any way to
dodge buster's bug, though.
regards, tom lane
