Re: [sqlite] [EXTERNAL] Re: sqlite3_progress_handler(D,N,X,P)

2018-05-25 Thread x
Thanks Max. It is a bit less cryptic. From: Max Vlasov<mailto:max.vla...@gmail.com> Sent: 25 May 2018 15:29 To: SQLite mailing list<mailto:sqlite-users@mailinglists.sqlite.org> Subject: Re: [sqlite] [EXTERNAL] Re: sqlite3_progress_handler(D,N,X,P) On Fri, May 25, 2018 at 10:29 A

Re: [sqlite] [EXTERNAL] Re: sqlite3_progress_handler(D,N,X,P)

2018-05-25 Thread Max Vlasov
On Fri, May 25, 2018 at 10:29 AM, x wrote: > You could have interrupt checks just before the return of a result row > yourself by creating a Step fct that called sqlite3_step and then checked > for an interrupt. It’s when the sqlite3.c code’s being run interrupt is > most

Re: [sqlite] [EXTERNAL] Re: sqlite3_progress_handler(D,N,X,P)

2018-05-25 Thread x
oun...@mailinglists.sqlite.org> on behalf of Hick Gunter <h...@scigames.at> Sent: Thursday, May 24, 2018 5:49:21 PM To: 'SQLite mailing list' Subject: Re: [sqlite] [EXTERNAL] Re: sqlite3_progress_handler(D,N,X,P) I can't tell without extensively looking into the source code. I expect not. From my experience I

Re: [sqlite] [EXTERNAL] Re: sqlite3_progress_handler(D,N,X,P)

2018-05-24 Thread Hick Gunter
I can't tell without extensively looking into the source code. I expect not. From my experience I would infer that ResultRow and maybe a few other VMIs are actual "interrupt points", because complex joins of virtual tables can continue for extended periods of time (and read tons of rows) before