I reached the same conclusion while experimenting with TAP coverage.
The query-driven RESET variable listing only triggers at the exact
… RESET <TAB> position, and does not support prefix-based matching
(e.g. RESET wo<TAB>). This leaves only list-style output
(RESET <TAB><TAB>), which is highly dependent on the readline/libedit
implementation and does not behave deterministically under the current
query_until()-based test harness. In practice this leads to timeouts
or flakiness, even though the behavior works correctly in interactive
psql sessions.
Given this, I agree that adding partial or unreliable TAP assertions
would be worse than omitting them. Keeping coverage for the deterministic
parts (keyword progression, database name completion, SET behavior) and
documenting why RESET variable listing is not asserted seems like the
most reasonable approach for now.
If, in the future, the TAP harness is extended to better support
query-driven list output during completion, this would be a good area
to revisit. I’d be happy to help explore that direction when such a
framework exists.
This patch added in commitfest
https://commitfest.postgresql.org/patch/6244/Thanks,
Vasuki M
C-DAC,Chennai
