On Jul 13, 2018, at 10:15 AM, dmp <[email protected]> wrote:
>
> Seems .dump uses a short output of skipping the column names.
To call that a problem requires that you justify why you’d need the column
names to be specified in the INSERT statements.
If you take the .dump file as-given and just run it, the INSERT statements are
fine as-is because the .dump file has a CREATE TABLE immediately above. There
can be no mismatch if you do not change the .dump file.
If you’re intending to edit the CREATE TABLE statements out of the .dump file
and run those INSERT statements on a SQLite DB with a different schema, then
yes, you’d need the column names to be explicitly provided, but that seems like
quite a special case. And of course, you could just edit the INSERT statements
at the same time.
> Always specifying the column names list
That’s good practice whenever there can be significant drift between the code
that does the CREATE TABLE call and the code that does the INSERT. For
example, if your application’s DB is initialized with a script and then
potentially years of software updates do ALTER TABLE calls on it on upgrades,
then yes, it’s important to qualify the column names in your INSERT statements.
> and using the database's
> identifier quoting character.
It does that at need already:
sqlite> create table "x y" ("a b" INTEGER);
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE IF NOT EXISTS "x y" ("a b" INTEGER);
COMMIT;
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
