.param init is not needed
(1) By Harald Hanche-Olsen (hanche) on 2022-01-13 15:24:17 [link] [source]
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 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
(2) By Larry Brasfield (larrybr) on 2022-01-13 16:03:18 in reply to 1 [link] [source]
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".
(3) By Richard Hipp (drh) on 2022-01-13 16:16:45 in reply to 2 [source]
My memory is that ".param init" was created precisely for the reason that Larry cites: To create the semi-magical temp.sqlite_parameters table, which is difficult to create otherwise.
(4) By Harald Hanche-Olsen (hanche) on 2022-01-13 16:27:04 in reply to 2 [link] [source]
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. ;-)