Re: [sqlite] Error message for nonsensical flags.

On 10 July 2017 at 00:22, Dan Ackroyd wrote: > Hi, > > I'm passing on an error report from a downstream library that uses > SQLite - https://bugs.php.net/bug.php?id=74883 - without having > tested that it is an accurate bug report. Apologies in advance if it > is a

Re: [sqlite] Cannot delete a Database file?

On 8 July 2017 at 10:48, Simon Slavin wrote: > On 8 Jul 2017, at 3:33am, domonic wrote: > > > No I just test the state > > of the database once and then test the output in my if statement. > > > > if(sqlite3_close(...)) > > { > > > > } > > else

Re: [sqlite] SQLITE_ERROR ("SQL error or missing database") should be split into two codes: "SQL error" and "missing database"

On 8 July 2017 at 03:28, Yuri wrote: > > There are some other problems in error definitions. For example, what does > SQLITE_FULL mean? How can database be full? Is it really a disk-full > condition? > > #define SQLITE_FULL13 /* Insertion failed because database is >

Re: [sqlite] VALUES clause quirk or bug?

On 9 Jul 2017, at 9:53pm, Keith Medcalf wrote: > Richard has checked in fixes for this on trunk which will likely appear in > the next release of SQLite. Presumably . Is the behaviour of column names now consistent

Re: [sqlite] acf3b9cc9c3932431979995a1dceacc06c659ab400fad95ce3728ff8895a022b : Off by one on the column names

On Sun, 09 Jul 2017 12:12:15 -0600, "Keith Medcalf" wrote: > >Off by one on the names: > >sqlite> values (1,2), (2,3); >column1|column2 >1|2 >2|3 > >sqlite> select * from (values (1,2), (2,3)); >column0|column1 >1|2 >2|3 Solved in === 2017-07-09 === 18:55:29 [70096c505d]

Re: [sqlite] VALUES clause quirk or bug?

Richard has checked in fixes for this on trunk which will likely appear in the next release of SQLite. Note this is a change to the underlying SQLite engine (SQLite3.dll) and not the command line shell. Column names from "values" are predictable and the same even in subqueries. Note that

Re: [sqlite] Concurrent reads for VTs with in-memory data structures

I presume only the data structure pointer is static -- the vtab/cursors still need to be dynamic .. I do not know why access to multiple separate instances of a virtual table would be serialized ... -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı > -Original Message- > From:

[sqlite] acf3b9cc9c3932431979995a1dceacc06c659ab400fad95ce3728ff8895a022b : Off by one on the column names

Off by one on the names: sqlite> values (1,2), (2,3); column1|column2 1|2 2|3 sqlite> select * from (values (1,2), (2,3)); column0|column1 1|2 2|3 --- Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in

[sqlite] Error message for nonsensical flags.

Hi, I'm passing on an error report from a downstream library that uses SQLite - https://bugs.php.net/bug.php?id=74883 - without having tested that it is an accurate bug report. Apologies in advance if it is a spurious bug report, however I don't currently have an environment to test it

[sqlite] appfileformat.html

Hi SQLITE Committers, I noticed a misspelling here: https://www.sqlite.org/appfileformat.html catagory is misspelled; it should be: category. First committed here: https://www.sqlite.org/docsrc/info/6d257b8d928cfd00 Thanks! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info

Re: [sqlite] cannot compile sqlite3 with intel compiler (ICC) - log and hints for a possible solution

On Sat, 8 Jul 2017, Richard Hipp wrote: (3) I compiled SQLite on each of gcc-5.4, gcc-7.1, clang-3.5, and icc-17.0 and compared both the size of the resulting binary and the performance. icc gave the largest binary and the slowest performance. Here are the actual results: gcc-5.4: 491585

Re: [sqlite] VALUES clause quirk or bug?

petern wrote: > I was hoping someone could shed light on what is actually going on in the > VALUE clause. VALUES (a, b), (c, d) ... is actually just a shortcut for SELECT a, b UNION ALL SELECT c, d ... If you want to control the column names, you have to use the second form with AS.

[sqlite] disabling quoting of newline in dump files (sqlite 3.19)

Hello All, (for details and motivations about my question, see also https://stackoverflow.com/q/44989176/841108 ...) I'm using the latest sqlite3 3.19.3 (the package version 3.19.3-3 of Linux/Debian/Sid/x86-64) I want that sqlite3 .dump outputs a dump file with newline characters

[sqlite] TEST: please ignore and delete

I'm just checking that the list is again reachable from Nabble after an admin changed the mail address from @sqlite.org to @mailinglists.sqlite.org http://sqlite.1065341.n5.nabble.com/ Admins: If need be, please delete this message later. -- View this message in context:

Re: [sqlite] VALUES clause quirk or bug?

On 2017/07/09 4:50 AM, petern wrote: The bug here is how the VALUES logic can't have it both ways. If double quotes are invalid for column value literals they should be rejected or at least ignored. They should not suddenly be injected into the column name(s) observed by the outer scope of the