(On argument for eliminating auto-header behavior for certain output modes:) > Mainly because this is a change in default behavior from previous versions It is a change, albeit one with rare impact for the reasons I stated. The argument against change carries more weight before the change has been released. Now, over 15 months later, that argument must be balanced against the guessed impact of changing it back to the pre-June-2020 behavior for people who may unknowingly rely on the auto-header feature. > ... we all appreciate the SQLite philosophy of backwards compatibility ... You should know (or "appreciate" ;-) that the value of backwards compatibility for the SQLite library is taken extremely seriously when changes are considered. For the CLI shell, that value is still given weight, but much less so than for the library. We consider the shell to be a convenience tool among its other virtues. For outputs that are generally meant for human rather than programmatic consumption, strict backward compatibility may be sacrificed for convenient invocation. (Hence, my "one-liner" reference earlier.) > ... adding code rather than removing – to restore previous capability regarding headers ... The reason for that is to retain invocation convenience (and 15-month-past backward compatibility) but not frustrate those who (like yourself) attempt to override the "default" columns output. > I’ve been using SQLite \[a lot.\] ... We try to keep you all happy or, failing that, to approach that state. I had the same sort of history with SQLite and appreciation of it. > I very much appreciate ... even if y’all can be a bit prickly sometimes. There are few if any mean bones to be found among the project members. It would probably be best to ascribe occasional abruptness or perhaps overly-pointed remarks to fatigue and pressure of other tasks.