I wrote:
> 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.
The current state of play on this is that I committed a hacky workaround
[1], but there is now a fix for it in libedit upstream [2][3]. I gather
from looking at Debian's package page that the fix could be expected to
propagate to Debian unstable within a few weeks, at which point I'd like
to revert the hack. The libedit bug's only been there a few months
(it was evidently introduced on 2019-03-31) so we can hope that it hasn't
propagated into any long-term-support distros.
> 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".
There's little we can do about that one, but it doesn't affect the
regression test as currently constituted.
Another libedit bug that the regression test *is* running into is that
some ancient versions fail to emit a trailing space after a successful
completion. snapper is hitting that [4], and I believe locust would
be if it were running the TAP tests. While we could work around that
by removing the trailing spaces from the match regexps, I really
don't wish to do so, because that destroys the test's ability to
distinguish correct outputs from incorrect-but-longer ones. (That's
not a killer problem for any of the current test cases, perhaps, but
I think it will be in future.) So I'd like to define this problem as
being out of scope. This bug was fixed eleven years ago upstream
(see change in _rl_completion_append_character_function in [5]), so
it seems reasonable to insist that people get a newer libedit or not
run this test.
Another issue visible in [4] is that ancient libedit fails to sort
the offered completion strings as one would expect. I don't see
much point in working around that either. prairiedog's host has
that bug but not the space bug (see [6], from before I suppressed
running the test on that machine), so it affects a larger range of
libedit versions, but they're probably all way too old for anyone
to care. If anyone can point to a new-enough-to-matter libedit
that still behaves that way, we can reconsider.
regards, tom lane
[1]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ddd87d564508bb1c80aac0a4439cfe74a3c203a9
[2] http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54510
[3]
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/filecomplete.c.diff?r1=1.63&r2=1.64
[4]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper&dt=2020-01-05%2013%3A01%3A46
[5]
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/readline.c.diff?r1=1.75&r2=1.76
[6]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2020-01-02%2022%3A52%3A36
