Christoph Berg <m...@debian.org> writes: > Re: Tom Lane 2020-01-02 <e1in6ft-0004zr...@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
