On Tuesday, 6 August, 2019 04:27, Olivier Mascia <o...@integral.be> inquired:
>On one database instance, a .dump command gives me (among many other
>lines) things like:
>
> INSERT INTO STATISTICS VALUES(11237795927160,11868);
>
>while the output of .recover command gives me things this way:
>
> INSERT INTO 'STATISTICS'('_rowid_', STATDATE, DISKUSED) VALUES(
>1, 11237795927160, 11868 );
>
>I'm wondering why these differences in the way to construct the
>instructions to rebuild a sound database instance. What are the
>(probably rightful) motivations?
>1) Why 'STATISTICS' (and not STATISTICS as in .dump command)? If
>escaping wanted, why not double quotes instead of single quotes?
This is a good question and the single quotes are bad syntax (or should be).
Identifier quoting should be using double-quotes. As to why identifier quotes
are included when not required, this is a matter of taste. Some people love
quotes. Some people use them only when necessary. Others deliberately choose
identifiers so quotes are never required. I happen to fall into the latter
camp.
>2) Why do the insert statement prefer to name and repeat, ad nausea,
>the column names on each insert when, apparently, the shortcut syntax
>capitalizing on the known column order in the schema might seem much
>less verbose?
In this particular case it is to preserve the _rowid_. The .recover command is
designed to "recover" the database, not merely ".dump" the data. Therefore, if
one wants to preserve the internal _rowid_ (because there is no explicitly
named INTEGER PRIMARY KEY for a rowid table, for example), the only way to do
so is to provide the list of attributes for which values are being provided.
--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
