.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 .param init
.
(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 [link] [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 [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. ;-)