I hate to be critical of Dr Hipp, but this commit stinks. Even if using the sqlite3 shell isn't the blessed way of producing a backup, I'm sure a lot of folks prefer it to the online backup API. It's this simple:
"echo .dump | sqlite3 my_db.db | gzip > my_db.sql.gz" That's beautiful. And now it doesn't work. What a horrible shock it was to discover that my backups were all of a sudden failing. I had no idea why until I checked the mailing list, which I luckily happen to be subscribed to, otherwise I'd still be puzzling over what happened. Please consider reverting this, or hiding this behavior behind a flag. On Tue, Apr 4, 2017 at 1:55 AM, Clemens Ladisch <clem...@ladisch.de> wrote: > James K. Lowden wrote: > >>> Why not use vis(3) instead? > >> > >> Because vis() is a nonstandard function that is not available > >> everywhere, > > > > "everywhere" is a high standard, but vis is freely available and > > included or packaged with almost anything not Windows. > > It is not included in the distribution that I happen to use. > > >> and in any case it does not support SQL. > > > > Entirely irrelevant, as you surely know. > > What?!? The .dump output _is_ SQL, and is intended to be read again > by SQLite, so whatever escaping mechanism it uses must be supported by > SQLite itself. > > > To me, the most objectionable aspect of using char() is that the SQL is > > munged. I see no reason to modify the user's text and introduce > > further SQL interpretation. > > The INSERT statements _already_ are interpreted; that's the whole point > of generating them in the first place. > > > Regards, > Clemens > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users