Re: TAP testing for psql's tab completion code

Hello Tom,

> We've often talked about the problem that we have no regression test
> coverage for psql's tab completion code. I got interested in this
> issue while messing with the filename completion logic therein [1],
> so here is a draft patch that adds some testing for that code.
>
> This is just preliminary investigation, so I've made no attempt
> to test tab-complete.c comprehensively (and I'm not sure there
> would be much point in covering every last code path in it anyway).
> Still, it does get us from zero to 43% coverage of that file
> already, and it does good things for the coverage of input.c
> and prompt.c as well.
>
> What I think is actually interesting at this stage is portability
> of the tests. There are a number of issues:
>
> * The script requires Perl's IO::Pty module (indirectly, in that IPC::Run
> requires that to make pty connections), which isn't installed everywhere.
> I just made the script skip if that's not available, so that we're not
> moving the goalposts for what has to be installed to run the TAP tests.
> Is that the right answer?
>
> * It seems pretty likely that this won't work on Windows, given all the
> caveats in the IPC::Run documentation about nonfunctionality of the pty
> support there. Maybe we don't care, seeing that we don't really support
> readline on Windows anyway. For the moment I assumed that the skip
> conditions for --without-readline and/or missing-IO::Pty would cover
> this, but we might need an explicit check for Windows too. Or maybe
> somebody wants to try to make it work on Windows; but that won't be me.
>
> * What's even more likely to be problematic is small variations in the
> output behavior of different readline and libedit versions. According
> to my tests so far, though, all modern versions of them do pass these
> test cases. I noted failures on very old Apple versions of libedit:
>
> 1. macOS 10.5's version of libedit seems not to honor
> rl_completion_append_character; it never emits the trailing space
> we're expecting. This seems like a plain old libedit bug, especially
> since 10.4's version works as expected.
>
> 2. Both 10.4 and 10.5 emit the alternative table names in the wrong
> order, suggesting that they're not internally sorting the completion
> results. If this proves to be more widespread, we could likely fix
> it by adding ORDER BY to the completion queries, but I'm not sure that
> it's worth doing if only these dead macOS versions have the issue.
> (On the other hand, it seems like bad practice to be issuing queries
> that have LIMIT without ORDER BY, so maybe we should fix them anyway.)
>
>
> I'm strongly tempted to just push this and see what the buildfarm
> thinks of it. If it fails in lots of places, maybe the idea is a
> dead end. If it works, I'd look into extending the tests --- in
> particular, I'd like to have some coverage for the filename
> completion logic.
>
> Thoughts?

After you raised the issue, I submitted something last August, which did
not attract much attention.

https://commitfest.postgresql.org/26/2262/

It covers some tab-completion stuff. It uses Expect for the interactive
stuff (tab completion, \h, ...).

--
Fabien.