This is a minor documentation nit, but:

In my experiments with the sqlite3 shell, I can set parameters without doing `.param init` manually. The `sqlite_parameters` table gets created automagically when needed. But the documentation seems to indicate otherwise, though it is not stated explicitly. In fact, as far as I have been able to find out by experimenting, `.param init` has no user-visible effect unless the user names the `sqlite_parameters` table explicitly.

Digging a bit further, this seems to have been the behaviour since the `.parameter` command was [introduced in checkin 1f9fa58541](https://www2.sqlite.org/cgi/src/info/1f9fa58541dc9749) a couple of years ago. (See the call to `bind_table_init(p)` in line 7158 of `src/shell.c.in` at the time of that checkin.

So my wild guess is that this line was added at a late stage of coding the feature, after the documentation had already been written. And ever since, people have just assumed one needs to run `.param init`.

If you regard the automagical creation of the temp.sqlite_parameters table as merely honoring Postel's law, then I would argue that you have not found a nit.

Running ".parameter init" does have a user-visible effect for those users who may wish to insert their own key/value pairs (or run "select * from temp.sqlite_parameters".) For those who wish to bypass ".parameter set ... ...", it is a convenience at a minimum and could work nicely with schema change protection schemes.

I think your guess is well grounded on the evidence, but not required by it.

A doc comment could be added to say it's not necessary, but then more comment would be due to explain why it exists, perhaps with a discussion of information hiding and provision for enhancement. All that considered, I'm inclined to maintain the present silence on this "necessity".

I think you exaggerate the need to explain. Those who know enough to access the `sqlite_parameters` table directly, also know enough not to be surprised by the consequences if it does not exist.

That said, when I look more closely at the documentation, I agree that it would require more than a minor rewrite to incorporate this nugget of information. It is quite possibly not worth the bother.

If I were to rewrite it, I would probably just describe `.param set/unset/list/clear` without reference to the underlying table, then explain the implementation next, including `.param init`. That *might* make the documentation more accessible to the casual user.

For my own part, I'll just stop writing `.param init` and get on with my life. ;-)