On Apr 7, 2017, at 10:45 AM, Warren Young wrote:
>
> (In my case, it was largely to avoid paying the cost of calling sqlite3
> thousands of times in a loop with near-identical SQL
I just remembered the other reason: because it’s easier to manage SQL quoting
rules in terms of Perl quoting rules
On Apr 7, 2017, at 1:14 AM, Dominique Devienne wrote:
>
> On Fri, Apr 7, 2017 at 5:02 AM, Charles Leifer wrote:
>
>> Is it conceivable that this change could be rolled back?
>
> ...their rule is "use only the official shell via
> scripts” and no C code
As one who just ported a shell script wr
On Fri, Apr 7, 2017 at 5:02 AM, Charles Leifer wrote:
> Is it conceivable that this change could be rolled back?
>
> On Tue, Apr 4, 2017 at 9:45 AM, Charles Leifer wrote:
> > I hate to be critical of Dr Hipp, but this commit stinks. Even if using
> > the sqlite3 shell isn't the blessed way of pr
Is it conceivable that this change could be rolled back?
On Tue, Apr 4, 2017 at 9:45 AM, Charles Leifer wrote:
> 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 onl
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
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 distribu
Charles Leifer wrote:
> This bit me... I fat-fingered a command and deleted my database. I had a
> backup dump taken earlier in the day. Go to restore it and all of a sudden
> this error starts cropping up.
>
> What to do?
From the link the in the first post:
sed -e "s/'||char(10)||'/\\n/g" < w
This bit me... I fat-fingered a command and deleted my database. I had a
backup dump taken earlier in the day. Go to restore it and all of a sudden
this error starts cropping up.
I'm stuck. I need to get this database back online, but even with 4000
limit I am losing INSERTs. I get segfaults when
On Sun, 2 Apr 2017 09:40:36 +0200
Clemens Ladisch 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. By u
James K. Lowden wrote:
> Clemens Ladisch wrote:
>
>> since commit 68f6dc7af1013f29, newlines in the .dump output are
>> escaped with char().
>
> Why not use vis(3) instead?
Because vis() is a nonstandard function that is not available everywhere,
and in any case it does not support SQL.
Regards
On Fri, 31 Mar 2017 21:59:05 +0200
Clemens Ladisch wrote:
> since commit 68f6dc7af1013f29, newlines in the .dump output are
> escaped with char().
Why not use vis(3) instead? No one seemed to notice when I offered
the suggestion.
Newline encoding is a solved problem. There's no need to to
Hi,
since commit 68f6dc7af1013f29, newlines in the .dump output are escaped
with char(). This can make the resulting SQL too complex:
$ sqlite3 test.db "create table t(x); insert into t
values(replace(printf('%1000s', ''), ' ', char(10)));"
$ sqlite3 test.db .dump | sqlite3
Error: near line 4:
12 matches
Mail list logo
