On 11/17/15, Yuri wrote:
>
> Don't keep the bag, keep only one integer ID of the first failed
> constraint.
Therein lays the rub: there is no way to tell which (if any) FK
constraint has failed until you have run the operation to the end and
checked them all. Remember, an FK constraint is
> It is a substantial change (basically a complete rewrite of the entire
> foreign key constraint mechanism) which would negatively impact both
> space and performance.
I think the argument is fallacious.
Don't keep the bag, keep only one integer ID of the first failed
constraint. That's all
I think there's a solution for this, which is, loosely, to run the constraint
tests twice, conditionally. That is, run it the current fast way as usual, and
then only if there is a failure, run the tests again the slower way that keeps
track of things so we know where the failure is. Since we
On 11/17/15, Yuri wrote:
> This message always leaves the user wondering: "Which constraint?"
>
> How hard is it to add this information to the message? Is this a matter
> of memorizing the ID of the constraint, and then printing its name in
> the message?
>
It is a substantial change (basically
On 11/17/15, Jonathan Metzman wrote:
>
> Thanks for the tip, I did get a bunch of garbage files that were written to
> the directory I was fuzzing from. What do you recommend doing instead?
>
https://www.sqlite.org/afl/doc/trunk/README.md
--
D. Richard Hipp
drh at sqlite.org
Great!
Thanks for the tip, I did get a bunch of garbage files that were written to
the directory I was fuzzing from. What do you recommend doing instead? (I
think I saw an sqlite_shell designed specifically for fuzzing somewhere on
your site)
On Tue, Nov 17, 2015 at 3:20 PM, Richard Hipp wrote:
On 11/17/15, Jonathan Metzman wrote:
> When fuzzing sqlite with American Fuzzy Lop, I believe I found the
> following bug in the sqlite shell:
>
Thanks for the report. Joe has checked in a fix.
Be careful about running AFL on the "sqlite3" command-line shell. AFL
might discover that it can
This message always leaves the user wondering: "Which constraint?"
How hard is it to add this information to the message? Is this a matter
of memorizing the ID of the constraint, and then printing its name in
the message?
Yuri
When fuzzing sqlite with American Fuzzy Lop, I believe I found the
following bug in the sqlite shell:
In shell.c:2563-2571 (in the amalgamated version), in the function
shell_dbinfo_command:
1. pFile is declared (2563): sqlite3_file *pFile;
2. Its address is passed to sqlite3_file_control
Thanks a lot both Igor and Simon for the quick response! Your two answers
settle my doubts.
On Mon, Nov 16, 2015 at 3:48 PM, Simon Slavin wrote:
> On 16 Nov 2015, at 12:24am, Randy Eels wrote:
>
> > My main question is: is an 'INTEGER PRIMARY KEY' column guaranteed not to
> > change, except as
With a compound index on ID and DATE performance is fine.
Thanks again.
RBS
On Tue, Nov 17, 2015 at 12:45 AM, Bart Smissaert
wrote:
> Actually it is slower than I thought, taking some 90 secs for only 7000
> records.
> Will if any compound index can speed this up.
>
> RBS
>
> On Tue, Nov 17,
Actually it is slower than I thought, taking some 90 secs for only 7000
records.
Will if any compound index can speed this up.
RBS
On Tue, Nov 17, 2015 at 12:09 AM, Igor Tandetnik wrote:
> On 11/16/2015 6:37 PM, Bart Smissaert wrote:
>
>> Now, what I need is for every row the count of
Thanks for that. I find that an amazing solution and one that I would never
have come up with.
Indeed a lot simpler (for me, that is) in application code, but for my
purpose this SQL is fine as my
numbers are small, thousands at most.
RBS
On Tue, Nov 17, 2015 at 12:09 AM, Igor Tandetnik wrote:
13 matches
Mail list logo
