[sqlite] Version 3.20.0 release candidate 2

We are restarting the test process for SQLite 3.20.0. There is a new release candidate on the website at https://sqlite.org/download.html and on the newly reopened branch-3.20 of the source tree at https://sqlite.org/src/timeline?r=branch-3.20 A new draft change log is at

Re: [sqlite] Version 3.20.0 release candidate 2

Union extension page has weird numbering on it for each sentence: https://sqlite.org/draft/unionvtab.html For the query in making a union vtab, is there a shorthand for "smallest/largest possible rowid" for columns 3 and 4 to say "just look at everything"? Definitely looks like an extension I

Re: [sqlite] New draft document on the new pointer-passing interfaces

On Tue, Jul 25, 2017 at 12:25 PM, petern wrote: > You're trying to change the topic to the security model. This thread is > supposed to be about a lengthy beyond the pale proposal that named all > manner of hypothetical boogie men before concluding the only way is a

Re: [sqlite] New draft document on the new pointer-passing interfaces

> On Jul 25, 2017, at 9:39 AM, Stephen Chrzanowski wrote: > > Your attitude towards a public forum and bully attempts isn't required > here. I'd ask YOU to leave based on the fact that your behavior is > anything but professional, as I'm not interested in your self

[sqlite] High memory usage for in-memory db with nested transactions

Hello everybody, The included C-Program takes a database file name as a command line parameter. I compiled it with SQLite 3.19.3 under Visual Studio 2017. If I supply test.db as a command line parameter / file name (and test.db doesn't exist yet) the size of test.db, the size of

Re: [sqlite] Version 3.20.0 release candidate 2

Also, I've just spotted the following (** characters surround the changes): 1) On the same page under " 2.1. Upping The Threat Level", the fourth paragraph starts: Because the pointer is passed in the t1.t1 column... I think this is meant to be: Because the pointer is passed in the

Re: [sqlite] New draft document on the new pointer-passing interfaces

Richard, Your description of the rational for the new pointer values is sound and quite reasonable. I believe that it meets all the requirements you have set out to prevent SQL from being used to either retrieve or set arbitrary internal use (that is internal to both the application and

Re: [sqlite] New draft document on the new pointer-passing interfaces

On 7/25/17, 11:25 AM, "sqlite-users on behalf of petern" wrote: > You're trying to change the topic to the security model. All I was doing was pointing out that hiding the type information from attackers is

Re: [sqlite] New draft document on the new pointer-passing interfaces

My tone isn't about the technical development discussion. Its about my subscribing to this forum and seeing my 11 year olds mentality shine through with his "I'm not getting the attention I want, so I'm going to yell and scream and pout until I get what I want". Perhaps it is a language barrier,

Re: [sqlite] Version 3.20.0 release candidate 2

Sorry, I should have said that item#4 in my last email should change 'facility' to 'facilitate'. Dave Ward Analytics Ltd - information in motion Tel: +44 (0) 118 9740191 Fax: +44 (0) 118 9740192 www: http://www.ward-analytics.com Registered office address: The Oriel, Sydenham Road, Guildford,

Re: [sqlite] Version 3.20.0 release candidate 2

In the release notes themselves: The sentence fragment “tab-completions…interfaces” was accidentally copied/pasted from the previous line: • Added the UNION virtual table extension. tab-completions for interactive user interfaces. This is a work in progress. Expect further enhancements

Re: [sqlite] High memory usage for in-memory db with nested transactions

On 25 Jul 2017, at 6:06pm, Brendan E. Coughlan wrote: > I compiled it with SQLite 3.19.3 under Visual Studio 2017. We’re going to presume Window 10 with all updates to date installed unless you tell us otherwise. Simon. ___

Re: [sqlite] Version 3.20.0 release candidate 2

Hi, Minor doc error at https://sqlite.org/draft/bindptr.html The first paragraph under "2. A Brief History Of Pointer Passing In SQLite" starts with: It is sometimes convenient for SQLite extensions to communicatin non-SQL values... I'm not sure what it is meant to say, but probably not

Re: [sqlite] Version 3.20.0 release candidate 2

Going on the snippet in David's correction only:  That arbitrary SQL was suppose to be run inside a sandbox where it could do ** no ** harm even if exploited It probably should be "was supposed". Graham. Original message From: David Wellman Date:

Re: [sqlite] New draft document on the new pointer-passing interfaces

You're trying to change the topic to the security model. This thread is supposed to be about a lengthy beyond the pale proposal that named all manner of hypothetical boogie men before concluding the only way is a "nuclear solution" as in: "Let's just nuke it, that's only way to be safe". I'll

Re: [sqlite] Version 3.20.0 release candidate 2

On 7/25/17, David Wellman wrote: > Hi, > > Minor doc error at https://sqlite.org/draft/bindptr.html > Typo fixed. Thanks. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list

Re: [sqlite] Version 3.20.0 release candidate 2

For the pragmas which an be used as functions, would it be possible to mark these somehow in the "List Of PRAGMAs" ? Perhaps PRAGMAs whih an be used as functions can have a normal bullet point and those which can’t have a "WHITE BULLET" instead. Or any other method of marking which appeals to

Re: [sqlite] High memory usage for in-memory db with nested transactions

On 7/25/17, Brendan E. Coughlan wrote: > > I compiled it with SQLite 3.19.3 under Visual Studio 2017. > > If I supply test.db as a command line parameter / file name (and test.db > doesn't exist yet) the size of test.db, the size of test.db.journal and > the program's

Re: [sqlite] New draft document on the new pointer-passing interfaces

On 7/24/17, petern wrote: > Great. But, if this is an ultimate replacement for BLOB'ed pointers, these > new pseudo-null pointers must support SQLITE_STATIC and destructor function > pointer lifetime disposition for those migrating their code. Nobody is forcing you

Re: [sqlite] High memory usage for in-memory db with nested transactions

> Memory usage tops out at 2,066,287,984 for me. That's pretty much all there is for a normal 32bit Windows process (2GB in user mode, a litte of which may be taken by user mode parts of the OS, the other 2GB reserved for Kernel mode). I hear 32bit Linux programmers get another GB of user

Re: [sqlite] High memory usage for in-memory db with nested transactions

Would you elaborate a bit more on that? To my untrained-in-C eyes it looks like there's the outer transaction, then a savepoint1, then a loop of (savepoint2, update the only record, release savepoint2). Is savepoint2 there not actually getting released each time? Wouldn't the outer transaction

Re: [sqlite] High memory usage for in-memory db with nested transactions

On 07/26/2017 12:58 AM, David Raymond wrote: Would you elaborate a bit more on that? To my untrained-in-C eyes it looks like there's the outer transaction, then a savepoint1, then a loop of (savepoint2, update the only record, release savepoint2). Is savepoint2 there not actually getting

Re: [sqlite] High memory usage for in-memory db with nested transactions

Thank you for the explanation. -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Dan Kennedy Sent: Tuesday, July 25, 2017 2:21 PM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] High memory usage for in-memory db with

Re: [sqlite] High memory usage for in-memory db with nested transactions

We’re going to presume Window 10 with all updates to date installed unless you tell us otherwise. Correct. I don't think it really matters though, since the situation I simplified it from runs on Window 7 and is compiled with VS2008, so it's probably not very new. Greetings, Brendan