Re: [sqlite] Truncation of floating point numbers in SQLite?

On Mon, Feb 2, 2015 at 8:08 PM, Donald Shepherd wrote: > sqlite3_bind_double calls sqlite3VdbeMemSetDouble which has a specific > check against NaN. My assumption is that this is what results in NaNs not > round tripping and instead coming back out as SQLITE_NULL: > >

Re: [sqlite] Truncation of floating point numbers in SQLite?

On Tue Feb 03 2015 at 12:23:29 PM James K. Lowden wrote: > On Sun, 1 Feb 2015 02:13:15 +0100 > Stephan Beal wrote: > > > On Sun, Feb 1, 2015 at 2:07 AM, Simon Slavin > > wrote: > > > > > So, having established that NaN and

Re: [sqlite] Truncation of floating point numbers in SQLite?

On Sun, 1 Feb 2015 02:13:15 +0100 Stephan Beal wrote: > On Sun, Feb 1, 2015 at 2:07 AM, Simon Slavin > wrote: > > > So, having established that NaN and -0 do not make the round trip > > from a C variable through a database and back into a C variable

Re: [sqlite] Possible to get list of terms in the Full Text Index?

Le 02.02.2015 18:00, sqlite-users-requ...@sqlite.org a écrit : Message: 1 Date: Sun, 01 Feb 2015 23:28:33 +0200 From: Rael Bauer To: sqlite-users@sqlite.org Subject: [sqlite] Possible to get list of terms in the Full Text Index? Message-ID:

Re: [sqlite] sqlite3 fails due to too long path (MAX_PATHNAME)

On Mon, 02 Feb 2015 12:59:55 +0200 Török Edwin wrote: > Would it be possible to raise that limit, or output a better error > message that says why it failed to open the file? Maybe. open(2) should return ENAMETOOLONG. It is possible, though unlikely these days, that

[sqlite] Final preparations for the release of System.Data.SQLite v1.0.95.0 have begun...

If you have any issues with the current code, please report them via this mailing list (and/or by creating a ticket on "https://system.data.sqlite.org/;) prior to Monday, February 9th. Pre-release packages are now available at:

Re: [sqlite] Encoding question

On 2015/02/02 19:37, Peter Haworth wrote: On Mon, Feb 2, 2015 at 9:00 AM, wrote: From: RSmith To: sqlite-users@sqlite.org Subject: Re: [sqlite] Encoding question Message-ID: <54cebb71.8060...@rsweb.co.za> Content-Type: text/plain;

Re: [sqlite] Performance increase between 3.7 and 3.8

On Mon, 2 Feb 2015 10:08:36 -0700 (MST) Jan Slodicka wrote: > I know the reports about huge performance increase achieved within > the last year. (Compliments for that.) However, those numbers ignore > processor architecture and I/O. My question is a different one. > > What

Re: [sqlite] Encoding question

On 2/2/15, Peter Haworth wrote: > I should also have mentioned that the question also included table names, > column names, constraint names, etc, but I'll assume the same applies to > them as for the data. > The schema is *always* in the database encoding. The SQLite parser

Re: [sqlite] Encoding question

On Mon, Feb 2, 2015 at 9:00 AM, wrote: > From: RSmith > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Encoding question > Message-ID: <54cebb71.8060...@rsweb.co.za> > Content-Type: text/plain; charset=windows-1252; format=flowed > > In

Re: [sqlite] Performance increase between 3.7 and 3.8

On 2/2/15, Jan Slodicka wrote: > I know the reports about huge performance increase achieved within the last > year. (Compliments for that.) However, those numbers ignore processor > architecture and I/O. My question is a different one. > > What speed difference do you perceive in

[sqlite] Performance increase between 3.7 and 3.8

I know the reports about huge performance increase achieved within the last year. (Compliments for that.) However, those numbers ignore processor architecture and I/O. My question is a different one. What speed difference do you perceive in real-world applications? I know that there can't be any

Re: [sqlite] regarding looping in vdbe for sqlite table joins!

SCAN in the query plan = Rewind...Next LOOP in opcodes SEARCH in the query plan = Column...Seek in opcodes SQLite has determined that creating an automatic index on the referenced tables should be faster than performing a full table scan for the general case. asql> explain query plan select *

Re: [sqlite] regarding looping in vdbe for sqlite table joins!

On 2/2/2015 10:24 AM, Sairam Gaddam wrote: Normally for executing joins in sqlite,the vdbe program opens 1 loop for each and every table What makes you believe that? but in my code(attached that file via pastebin) ,i am facing an issue because it is opening only 2 loops even if i use 4

[sqlite] regarding looping in vdbe for sqlite table joins!

Normally for executing joins in sqlite,the vdbe program opens 1 loop for each and every table but in my code(attached that file via pastebin) ,i am facing an issue because it is opening only 2 loops even if i use 4 tables in joining operation. can anyone explain why it happened like that and

Re: [sqlite] sqlite3 fails due to too long path (MAX_PATHNAME)

2015-02-02 11:59 GMT+01:00 Török Edwin : > Would it be possible to raise that limit, or output a better error message > that says why it failed to open the file? My suggestion would be to add something like this to sqliteLimit.h: /* ** Maximum supported

[sqlite] sqlite3 fails due to too long path (MAX_PATHNAME)

Hi, I was testing long pathnames and ran into this failure: $ sqlite3