Small requests, small answers: a misleading error, a SHOW CREATE, a docs wish and a paste

Not every issue I filed deserves its own post. Four small ones, most substantial first.

• A tuple IN that blamed the wrong thing (#34810). (a, b) IN (SELECT (c, d) ...) worked when the tuple types matched exactly and failed when integer widths differed, with “Number of columns in section IN doesn’t match. 2 at left, 1 at right”, which was false. The first reply took the message at its word and suggested rewriting the subquery; I asked why the other form worked, and the issue was reopened. It was a real defect, fixed by vdimir in PR #34836 (merged 2022-02-25, in 22.3) with the issue’s example as a regression test. The fix is better than the message I asked for: the query just evaluates. Confirmed on 26.4 with Tuple(UInt64, DateTime) against Tuple(UInt32, DateTime).
• SHOW CREATE TABLE on a table function (#34967). Declined: remote(...) builds a temporary Distributed table with no CREATE of its own, and can read many differently created tables. Read system.tables through remote instead. CREATE TABLE t AS numbers(5) then SHOW CREATE TABLE t works and keeps AS numbers(5); SHOW CREATE TABLE numbers(5) is a syntax error on 26.4. A reason I accept.
• A documentation suggestion (#1127, 2017). I proposed community-editable docs. A year later a maintainer pointed out the docs already lived in the repository, and every page has an edit link. I was glad to be wrong.
• Pasting multi-line SQL (#13967, 2020). In 20.6 each pasted line ran as its own query. The answer was -n (--multiquery) without -m. I closed it myself, and have not retested the default on a current interactive client.

A fifth issue, #20546, was a plain question about deleting a row in EmbeddedRocksDB; it is answered in passing in the EmbeddedRocksDB post.