Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

I just want to point something out that might help the original poster. On Saturday, March 7, 2020, 7:00:21 AM EST, sqlite-users-requ...@mailinglists.sqlite.org wrote: > > 1.  NULL is NULL = Yes, True, > 2.  NULL is FALSE = Nope, False. > 3.  NULL is TRUE  = Nope, False. > 4.  NULL is

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 2020/03/07 03:52, Xinyue Chen wrote: Hi, If I change IS NOT FALSE to IS TRUE, the results will be different. I assume they should perform in the same way? if you say "NULL IS NOT FALSE" is always true, then 'NULL IS TRUE' should also be always true. Then why doesn't that query also return 4

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/20 9:54 PM, Keith Medcalf wrote: On Friday, 6 March, 2020 19:25, Richard Damon wrote: It is sort of like NaN, where a Nan is neither less than, greater than or equal to any value, including itself. NULL (as in SQL NULL) means "missing value" or "unknown". NULL represents any value

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On Friday, 6 March, 2020 19:25, Richard Damon wrote: >It is sort of like NaN, where a Nan is neither less than, greater than >or equal to any value, including itself. NULL (as in SQL NULL) means "missing value" or "unknown". NULL represents any value within the domain, we simply do not know

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/20 9:00 PM, Simon Slavin wrote: On 7 Mar 2020, at 1:52am, Xinyue Chen wrote: If I change IS NOT FALSE to IS TRUE, the results will be different. I assume they should perform in the same way? No. Because NULL is not TRUE and is not FALSE. SQLite version 3.28.0 2019-04-15 14:49:49

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/2020 8:52 PM, Xinyue Chen wrote: If I change IS NOT FALSE to IS TRUE, the results will be different. NULL IS TRUE is always false. NULL IS NOT FALSE is always true. So it's not surprising that the results are different. SQL uses trivalent logic. NULL is neither FALSE nor TRUE. I

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 7 Mar 2020, at 1:52am, Xinyue Chen wrote: > If I change IS NOT FALSE to IS TRUE, the results will be different. I > assume they should perform in the same way? No. Because NULL is not TRUE and is not FALSE. SQLite version 3.28.0 2019-04-15 14:49:49 Enter ".help" for usage hints. Connected

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

> If I change IS NOT FALSE to IS TRUE, the results will be different. I > assume they should perform in the same way? > if you say "NULL IS NOT FALSE" is always true, then 'NULL IS TRUE' should > also be always true. "NULL IS NOT FALSE" is true because NULL is not a value therefor it is not

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

Hi, If I change IS NOT FALSE to IS TRUE, the results will be different. I assume they should perform in the same way? if you say "NULL IS NOT FALSE" is always true, then 'NULL IS TRUE' should also be always true. Then why doesn't that query also return 4 rows? Thanks! On Fri, Mar 6, 2020 at 5:45

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On Friday, 6 March, 2020 17:48 Xinyue Chen wrote: ... >select t1.textid a, i.intid b > from t t1, > i i > where (t1.textid = i.intid and t1.textid in (12) and t1.textid = i.intid) >or (t1.textid = null IS NOT FALSE) >group by i.intid, t1.textid; I got rid of all the extra brackets

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

Change the "(t1.textid = null)" to "(t1.textid IS NULL)". Null has no value, you have to check for it explicitly. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug in SQLite version 3.31.1 and 3.32?

On 3/6/20, Xinyue Chen wrote: > -- Buggy query > select t1.textid a, i.intid b > from t t1, > i i > where (((t1.textid = i.intid) and (t1.textid in (12)) and (t1.textid = > i.intid)) or ((t1.textid = null) IS NOT FALSE)) > group by i.intid, t1.textid; (1) The expression "t1.textid=null" is

[sqlite] Bug in SQLite version 3.31.1 and 3.32?

Hi, I am not sure if I found a bug in SQLite version 3.31.1 and 3.32. Could you please check? CREATE TABLE t ( textid TEXT ); INSERT INTO t VALUES ('12'); INSERT INTO t VALUES ('34'); CREATE TABLE i ( intid INTEGER PRIMARY KEY ); INSERT INTO i VALUES (12); INSERT INTO i VALUES (34); CREATE

Re: [sqlite] bug report (INSTR() ignores NOCASE on columns)

Stephan Senzel, on Sunday, February 2, 2020 08:12 AM, wrote... > > INSTR() ignores NOCASE on columns > > --- > > example: > > SELECT * FROM table WHERE INSTR(column, ' castle ') > 0 > > returns datasets with 'castle' only, without 'Castle', even if the > column is set to

[sqlite] bug report (INSTR() ignores NOCASE on columns)

INSTR() ignores NOCASE on columns --- example: SELECT * FROM table WHERE INSTR(column, ' castle ') > 0 returns datasets with 'castle' only, without 'Castle', even if the column is set to NOCASE --- LIKE doesn't have this problem, works well SELECT

Re: [sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

As I understand it, the barrier in that patch ensures that for whichever thread executes the if(!sqlite3GlobalConfig.mutex.xMutexAlloc codepath) {...}, the write to pTo->xMutexAlloc will be stored after the rest of the xMutex* field writes. But there's nothing preventing another thread *loading*

Re: [sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

On 1/28/20, Oystein Eftevaag wrote: > in sqlite3MutexInit() sqlite3GlobalConfig.mutex.xMutexAlloc > can be read as being set on a core, while the rest of the initialization > done in sqlite3MutexInit() still is being read as unset. Doesn't the memory barrier at

[sqlite] Bug report: Potential thread safety issues in sqlite3_initialize

Hi folks, Data races in sqlite3_initialize was previously reported in https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg94225.html and a fix landed, however while investigating internal TSan reports of this, as far as we can tell the issue is still present (on non-x86 platforms

Re: [sqlite] BUG(?) in FTS5

Hi Jens, the MATCH operator is not inside an OR expression. The MATCH operator is in an AND expression, only the rowid request is in an OR expression. Regards, Hartwig PS: In FTS5 since version 3.30.1 also the MATCH operator is allowed in OR statements (try SELECT PlayersFTS.rowid FROM

Re: [sqlite] Bug report

On Jan 23, 2020, at 7:02 AM, Mark Benningfield wrote: > > ...whenever I do a Fossil pull of the latest > version takes a grand total of about 2 seconds, but it would be nice not to > have to remember to do it every time :) If you’re having to reapply the change on every Fossil update, you’re

Re: [sqlite] BUG(?) in FTS5

> On Jan 23, 2020, at 6:47 AM, mailing lists wrote: > > The following SELECT statement fails with the error "unable to use function > MATCH in the requested context": This is an annoying but documented limitation of FTS, not a bug. The MATCH operator can’t be used inside an OR expression. It

[sqlite] BUG(?) in FTS5

Hi, create and fill the tables: CREATE TABLE Games (ID INTEGER PRIMARY KEY, WhiteID INTEGER, BlackID INTEGER); CREATE VIRTUAL TABLE PlayersFTS USING FTS5 (LastName,FirstNames); INSERT INTO Games (WhiteID,BlackID) VALUES(1,2); INSERT INTO PlayersFTS (rowid,LastName,FirstNames) VALUES(1,'A','1');

Re: [sqlite] Bug report

Well, I kinda thought that this would be fixed on the next release. The "value_frombind" typo in particular prevents FTS3/4 from being built as a loadable extension. I only have one legacy application that uses FTS3/4 that way, and fixing these typos whenever I do a Fossil pull of the latest

Re: [sqlite] bug on zPath length

On 1/23/20, Ondrej Dubaj wrote: > I discovered an issue found by coverity scan. Thanks for the report. This was previously fixed here: https://www.sqlite.org/src/info/465a15c5c2077011 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list

[sqlite] bug on zPath length

Hi, I discovered an issue found by coverity scan. sqlite-src-326/shell.c:5697: var_compare_op: Comparing "zFree" to null implies that "zFree" might be null. sqlite-src-326/shell.c:5698: alias_transfer: Assigning: "zPath" = "zFree". sqlite-src-326/shell.c:5699: var_deref_model: Passing

[sqlite] Bug? SQLITE_DEFAULT_DEFENSIVE and CLI .parameters

Defining SQLITE_DEFAULT_DEFENSIVE prevents proper working of the CLI .parameter commands. SQLite version 3.31.0 2020-01-19 18:49:07 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> .schema sqlite> .param

Re: [sqlite] Bug fixes only branch.

On 1/13/20, Syed Ahmad wrote: > We are at 3.14.2 > > Current version = 3.14.2 Date : 2016-09-12 > > https://www.sqlite.org/changes.html > > how can i take latest stable branch which include only bug fixes . no new > features. > > Is there any way? We sometimes do things like that for paid

Re: [sqlite] Bug fixes only branch.

On Monday, 13 January, 2020 15:00, Donald Griggs wrote: >On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad >wrote: >> We are at 3.14.2 Date : 2016-09-12 >> how can i take latest stable branch which include only bug fixes . no >> new features. >> Is there any way? > I may well not be

Re: [sqlite] Bug fixes only branch.

On Tue, 14 Jan 2020 at 7:00 am, Donald Griggs wrote: > Hi, Syed, > > === > On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad > wrote: > > > We are at 3.14.2 Date : 2016-09-12 > > > > how can i take latest stable branch which include only bug fixes . no new > > features.

Re: [sqlite] Bug fixes only branch.

Hi, Syed, === On Mon, Jan 13, 2020 at 11:34 AM Syed Ahmad wrote: > We are at 3.14.2 Date : 2016-09-12 > > how can i take latest stable branch which include only bug fixes . no new > features. > > Is there any way? > == I may well not

[sqlite] Bug fixes only branch.

We are at 3.14.2 Current version = 3.14.2 Date : 2016-09-12 https://www.sqlite.org/changes.html how can i take latest stable branch which include only bug fixes . no new features. Is there any way? ___ sqlite-users mailing list

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

Hi, On Tue, Jan 7, 2020 at 2:01 AM Clemens Ladisch wrote: > > Richard Hipp wrote: > > On 1/5/20, Keith Medcalf wrote: > >> select * from a, b, c using (id); -- very strange result > > > > PostgreSQL and MySQL process the query as follows: > > > >SELECT * FROM a, (b JOIN c USING(id)); > > >

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

Richard Hipp wrote: > On 1/5/20, Keith Medcalf wrote: >> select * from a, b, c using (id); -- very strange result > > PostgreSQL and MySQL process the query as follows: > >SELECT * FROM a, (b JOIN c USING(id)); > > SQLite processes the query like this: > >SELECT * FROM (a,b) JOIN c USING

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

On Sunday, 5 January, 2020 04:42, Richard Hipp wrote: >On 1/5/20, Keith Medcalf wrote: >> Hrm. Inconsistent/incorrect results. Consider: >> create table a(id integer primary key, a); >> insert into a values (1,1), (2,1), (3,1); >> create table b(id integer primary key, b); >> insert into b

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

> On 1/5/20, Keith Medcalf wrote: >> >> Hrm. Inconsistent/incorrect results. Consider: >> >> create table a(id integer primary key, a); >> insert into a values (1,1), (2,1), (3,1); >> create table b(id integer primary key, b); >> insert into b values (1,2), (3,2), (4,2); >> create table c(id

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

On 1/5/20, Richard Hipp wrote: > > Note that both MySQL and SQLite do allow you to use parentheses, as > shown in my examples, to define the order of evaluation. PostgreSQL > does not, sadly. > Apparently, in PostgreSQL you have to say: SELECT * FROM (SELECT * FROM a, b) AS x JOIN c

Re: [sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

On 1/5/20, Keith Medcalf wrote: > > Hrm. Inconsistent/incorrect results. Consider: > > create table a(id integer primary key, a); > insert into a values (1,1), (2,1), (3,1); > create table b(id integer primary key, b); > insert into b values (1,2), (3,2), (4,2); > create table c(id integer

[sqlite] Bug? SQLite command-line result is different from Perl DBI::Sqlite result

Hrm. Inconsistent/incorrect results. Consider: create table a(id integer primary key, a); insert into a values (1,1), (2,1), (3,1); create table b(id integer primary key, b); insert into b values (1,2), (3,2), (4,2); create table c(id integer primary key, c); insert into c values (1,3), (4,3),

Re: [sqlite] Bug Report

Bigthing Do, on Friday, December 27, 2019 01:56 PM, wrote... > > Dear sqlite developers: > > We met an accidental crash in sqlite with the following sample: > > CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 > ) SELECT col2 FROM table1 ORDER BY 1 ; > WITH aaa AS ( SELECT

Re: [sqlite] Bug Report

Hi, We tried debugging a little bit with the core dump, it crashes with a null reference actually: ` Program received signal SIGSEGV, Segmentation fault. [--registers---] RAX: 0x74 ('t') RBX: 0x782550 --> 0x76b088 --> 0x1 RCX:

Re: [sqlite] Bug Report

On Friday, 27 December, 2019 12:50, Igor Korot wrote: >On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote: >> We met an accidental crash in sqlite with the following sample: >> CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) >> SELECT col2 FROM table1 ORDER BY 1 ;

Re: [sqlite] Bug Report

Hi, On Fri, Dec 27, 2019 at 12:57 PM Bigthing Do wrote: > > Dear sqlite developers: > > We met an accidental crash in sqlite with the following sample: > > CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) > SELECT col2 FROM table1 ORDER BY 1 ; > WITH aaa AS ( SELECT *

[sqlite] Bug Report

Dear sqlite developers: We met an accidental crash in sqlite with the following sample: CREATE VIEW table1 ( col1 , col2 ) AS WITH aaa AS ( SELECT * FROM table1 ) SELECT col2 FROM table1 ORDER BY 1 ; WITH aaa AS ( SELECT * FROM table1 ) SELECT col1 , rank () OVER( ORDER BY col1 DESC ) FROM

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

On 21 Dec 2019, at 21:42, Michael Walker (barrucadu) wrote: > I'm not sure the attachment to my first email got through ... Correct. The list strips them. -- Cheers -- Tim ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

The mailing list strips attachments, btw. Anyways, looking at that, yeah, they're all text values: sqlite> SELECT bookIsbn, typeof(bookIsbn) FROM books WHERE bookAuthor LIKE '%Ambrose%'; bookIsbntypeof(bookIsbn) -- 0486280381 text 9781496030 text 9781496030 text

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

Hi Shawn, Thanks for your response. Though that doesn't seem to be the case: sqlite> select bookIsbn, typeof(bookIsbn) from books where bookIsbn = "9781496030825"; 9781496030825|text sqlite> select bookIsbn, typeof(bookIsbn) from books where bookIsbn = "9780099477310"; 9780099477310|text The

Re: [sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

Without seeing your table definition, this is just a guess, but maybe the duplicate keys are stored as different types, with the primary key column having an affinity that doesn't force one particular storage class: sqlite> CREATE TABLE test(id PRIMARY KEY); sqlite> INSERT INTO test

[sqlite] Bug: Table contains two records for the same primary key in .dump output but not in SELECT output

Hi, I've somehow ended up with a table which contains two records for the same primary key - well actually I've got two primary keys like that, so I have four records with two primary keys between them. I've been unable to reproduce this from a clean database, so I attach my database file to

[sqlite] Bug report

In version 3.30.1 ( check-in [9b14eb77] ), file "sqlite3ext.h" 618 #define sqlite3_stmt_isexplain sqlite3_api->isexplain 619 #define sqlite3_value_frombind sqlite3_api->frombind should be 618 #define sqlite3_stmt_isexplain sqlite3_api->stmt_isexplain 619 #define

Re: [sqlite] Bug report: cppcheck memory leak

On 2 Dec 2019, at 1:16am, Richard Hipp wrote: > Telling us that the > "return" from malloc() is a memory leak is not helpful information, > even if it were true. Oh, someone needs to write a story about a manager who doesn't understand computers but relies on test suites, and programmers

Re: [sqlite] Bug report: cppcheck memory leak

On 12/1/19, David Brouwer wrote: > While playing around with static code analysis with cppcheck, I ran into > the error "[modules/sqlite3_omit.c:22845]: (error) Memory leak: p". I can't > tell whether it's significant or not, but I figured I'd report it anyway. Thanks for taking the time to

[sqlite] Bug report: cppcheck memory leak

Dear, Title: Potential memory leak reported by cppcheck Version: 3.27.2 While playing around with static code analysis with cppcheck, I ran into the error "[modules/sqlite3_omit.c:22845]: (error) Memory leak: p". I can't tell whether it's significant or not, but I figured I'd report it anyway.

Re: [sqlite] Bug report

CVE will not record this bug if it doesn't affect a /released/ version of any product. One hopes that none of the products which incorporate SQLite would incorporate a version of SQLite which never received a release number. In other words, the reporters told the developer team before the bug

Re: [sqlite] Bug report

On Thu, 21 Nov 2019 21:02:57 +, Jose Isaias Cabrera wrote: >Kees Nuyt, on Thursday, November 21, 2019 03:48 PM, wrote... [...] >> >> I see no CVE entered by the OP, but maybe I missed something. > > Yes, you are right. After pasting it, I went through the top 5 > and none of these

Re: [sqlite] Bug report

Kees Nuyt, on Thursday, November 21, 2019 03:48 PM, wrote... > > > Thanks, Jose. > > I see no CVE entered by the OP, but maybe I missed something. Yes, you are right. After pasting it, I went through the top 5 and none of these aren't/weren't the one. Apologies. I thought that by searching on

Re: [sqlite] Bug report

Thanks, Jose. I see no CVE entered by the OP, but maybe I missed something. A quick look to your list : > NameDescription > CVE-2019-9937 > In SQLite 3.27.2, interleaving reads and writes in a single transaction with > an fts5

Re: [sqlite] Bug report

On 11/19/19, Yongheng Chen wrote: > Hi, > > This is Yongheng Chen from Gatech and Rui Zhong from PSU. We found 7 crashes > for sqlite of the newest commit 3842e8f166e23a1ed6e6094105e7a23502d414da. > We have attached the samples that crash sqlite in the email. FYI, we have > also reported the

Re: [sqlite] Bug report

software versions prior to v1.3.4. The underlying SQLite database query is subject to SQL injection on the username input parameter. From: sqlite-users on behalf of Kees Nuyt Sent: Thursday, November 21, 2019 09:51 AM To: sqlite-users@mailinglists.sqlite.org Subj

Re: [sqlite] Bug report

On Tue, 19 Nov 2019 00:19:13 -0500, you wrote: > Hi, > > This is Yongheng Chen from Gatech and Rui Zhong from PSU. > We found 7 crashes for sqlite of the newest commit > 3842e8f166e23a1ed6e6094105e7a23502d414da. > We have attached the samples that crash sqlite in the email. The mailing list

[sqlite] Bug report

Hi, This is Yongheng Chen from Gatech and Rui Zhong from PSU. We found 7 crashes for sqlite of the newest commit 3842e8f166e23a1ed6e6094105e7a23502d414da. We have attached the samples that crash sqlite in the email. FYI, we have also reported the bugs for CVE at cve.mitre.org

Re: [sqlite] BUG and WORKAROUND sqlite3 shell .parameter command evaluating arguments when it shouldn't.

I think this is a bug. However, looking at the code the way to achieve that is to surround the string in double quotes which will cause exactly what appears between the double-quotes to be stored. I think it is because of the way the parsing and mprintf function works ... sqlite> .param

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On Friday, 1 November, 2019 10:20, Simon Slavin wrote: >On 1 Nov 2019, at 4:17pm, Simon Slavin wrote: >WHERE (c1 IS NULL) OR (C1 != 2) > which could quite reasonably return rows. However, the NULL possibility > may be redundant. I can't tell without tests. The expression NOT (c1 IS

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On Friday, 1 November, 2019 09:12, And Clover wrote: > CREATE TABLE t0 (c0); > CREATE TABLE t1 (c1); > INSERT INTO t0 VALUES (1); > SELECT c0 > FROM t0 LEFT JOIN t1 ON c1=c0 > WHERE NOT (c1 IS NOT NULL AND c1=2); >Expected result: (1) >Actual result: no rows

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On 01/11/2019 16:20, Simon Slavin wrote: It is actually WHERE (c1 IS NULL) OR (C1 != 2) which could quite reasonably return rows. Yes, and with this OR filter the quoted example does indeed return rows. The version with: WHERE NOT (c1 IS NOT NULL AND c1=2) *should* be equivalent to

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On 1 Nov 2019, at 4:17pm, Simon Slavin wrote: > This is a cut-down example, right ? You can't possibly mean to do that WHERE > clause in production code. It amounts to > >WHERE (c1 IS NULL) AND (C1 != 2) I'm so sorry. It is actually WHERE (c1 IS NULL) OR (C1 != 2) which could

Re: [sqlite] Bug submission: left join filter on negated expression including NOTNULL

On 1 Nov 2019, at 3:12pm, And Clover wrote: >WHERE NOT (c1 IS NOT NULL AND c1=2); > > Expected result: (1) > Actual result: no rows returned This is a cut-down example, right ? You can't possibly mean to do that WHERE clause in production code. It amounts to WHERE (c1 IS NULL)

[sqlite] Bug submission: left join filter on negated expression including NOTNULL

Hi, CREATE TABLE t0 (c0); CREATE TABLE t1 (c1); INSERT INTO t0 VALUES (1); SELECT c0 FROM t0 LEFT JOIN t1 ON c1=c0 WHERE NOT (c1 IS NOT NULL AND c1=2); Expected result: (1) Actual result: no rows returned This appears to be a regression in 3.30; 3.29 and earlier

Re: [sqlite] Bug: Infite loop on SELECT with .explain on

ays a lot about anticipated traffic volume. >-Original Message- >From: sqlite-users On >Behalf Of Richard Hipp >Sent: Saturday, 26 October, 2019 10:08 >To: SQLite mailing list >Subject: Re: [sqlite] Bug: Infite loop on SELECT with .explain on > >Thanks for the repor

Re: [sqlite] Bug: Infite loop on SELECT with .explain on

Thanks for the report. This problem is fixed on trunk. To be clear, this is an issue in the "sqlite3" shell command, not in the SQLite core. Also, it is an issue in the deprecated and undocumented ".explain on" command of the shell. Years ago, it used to be necessary to run ".explain on" prior

[sqlite] Bug: Infite loop on SELECT with .explain on

I am running sqlite3 on a Linux Mint 18 desktop. I first realized the problem with the stock sqlite3 client 3.11.0 2016-02-15 17:29:24 3d862f207e3adc00f78066799ac5a8c282430a5f. I confirmed it still exists with the currently published most recent version 3.30.1 2019-10-10 20:19:45

Re: [sqlite] Bug: WINDOW clause within a CTE

On 15/9/62 11:57, Jake Thaw wrote: The following examples demonstrate a possible bug when using a WINDOW clause within a CTE: SQLite version 3.30.0 2019-09-14 16:44:51 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent

[sqlite] Bug: WINDOW clause within a CTE

The following examples demonstrate a possible bug when using a WINDOW clause within a CTE: SQLite version 3.30.0 2019-09-14 16:44:51 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> CREATE TABLE x AS

[sqlite] Bug with json_group_array() as a window function

Using 3.29 and a 3.30 snapshot: When using json_group_array() as a window function, it loses the tagging of its argument as being JSON, treating JSON objects etc. as strings instead when creating arrays. Sample table: CREATE TABLE testjson(id INTEGER PRIMARY KEY, j TEXT); INSERT INTO testjson

[sqlite] Bug in checkin e2c6fed8f8 vtab.c sqlite3_drop_modules with SQLITE_ENABLE_API_ARMOR: zName is undeclared

SQLITE_API int sqlite3_drop_modules(sqlite3 *db, const char** azNames){ HashElem *pThis, *pNext; #ifdef SQLITE_ENABLE_API_ARMOR if( !sqlite3SafetyCheckOk(db) || zName==0 ) return SQLITE_MISUSE_BKPT; #endif for(pThis=sqliteHashFirst(>aModule); pThis; pThis=pNext){ Module *pMod =

[sqlite] bug: typo in sqlite3.n

From sqlite-autoconf-329: tea/doc/sqlite3.n says "SQLite3 is a self-contains". It should be "contained" instead. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Bug report: DROP TABLE while a cursor is open leads to SQLITE_LOCKED

Hi, sorry for the repost. I just noticed that I probably should have added "Bug report" in the subject line. I'm using the Xerial JDBC driver for accessing SQLite (but this issue is not directly related to the driver). I have the problem that it is not possible to drop a table in the same

Re: [sqlite] Bug: LSM1 lsm1BestIndex() always chooses table scan

On 8/16/19, James Kafader wrote: > > We think, after trying out a fix that line 845 of lsm_vtab.c contains a > bug. This line > for(i=0; inConstraint && idxNum<16; i++, pConstraint++){ > should perhaps be replaced by this line: >for(i=0; inConstraint && idxNum>16; i++, pConstraint++){ >

[sqlite] Bug: LSM1 lsm1BestIndex() always chooses table scan

Hi SQLite devs, I'd like to begin with a "thank you" for a great tool that we use every day at Internet Archive. We are currently considering SQLite's LSM engine (we are aware it is not considered production quality) to implement a index server process that will underpin the Wayback Machine's

[sqlite] Bug report: documentation for the SQLite Android bindings should clearly call out their poor query performance

I apologize in advance if this is the wrong place to report bugs with the SQLite Android bindings, but I couldn’t figure out how to file a ticket on that subsite (https://sqlite.org/android/) and didn’t see any contact information there, so I figured I’d try here. Query performance,

Re: [sqlite] Bug report: crash when close blob handle after close_v2 db

On 14/7/62 17:18, Chaoji Li wrote: This problem is only present for 3.28+. A sample test case is attached. Thanks for reporting this. We think it's fixed here:   https://sqlite.org/src/info/52f463d29407fad6 The mailing list stripped off your test case, so if you could either run it with

Re: [sqlite] Bug when creating a table via select?

On Mon, Jul 15, 2019 at 6:01 AM J. King wrote: > On July 14, 2019 11:56:15 p.m. EDT, Donald Shepherd < > donald.sheph...@gmail.com> wrote: > >sqlite> create table x(a int, b text, c real, d blob, e vartext, > fgarbage); > >sqlite> pragma table_info(x); > >0|a|int|0||0 > >1|b|text|0||0 >

Re: [sqlite] Bug when creating a table via select?

On July 15, 2019 12:01:00 a.m. EDT, "J. King" wrote: >On July 14, 2019 11:56:15 p.m. EDT, Donald Shepherd > wrote: >>Somewhat bizarrely only "BLOB" affinity doesn't make it from the >>original >>table to the new table when using the "select" syntax to create the >new >>table. Even items with

Re: [sqlite] Bug when creating a table via select?

On July 14, 2019 11:56:15 p.m. EDT, Donald Shepherd wrote: >Somewhat bizarrely only "BLOB" affinity doesn't make it from the >original >table to the new table when using the "select" syntax to create the new >table. Even items with aliased affinities (VARTEXT, or something that >defaults to

[sqlite] Bug when creating a table via select?

Somewhat bizarrely only "BLOB" affinity doesn't make it from the original table to the new table when using the "select" syntax to create the new table. Even items with aliased affinities (VARTEXT, or something that defaults to NUMERIC) comes across as the base affinity but at least have an

Re: [sqlite] Bug report: crash when close blob handle after close_v2 db

On 14 Jul 2019, at 11:18am, Chaoji Li wrote: > This problem is only present for 3.28+. A sample test case is attached. Thank you for identifying this behaviour. I'm sure the development team will reply to your post. Attachments are automatically ignored by the mailing list. You can include

[sqlite] Bug report: crash when close blob handle after close_v2 db

This problem is only present for 3.28+. A sample test case is attached. Basically, the flow is: 1. Open in-memory db A (we don't do anything about it). 2. Open db B from file test.db 3. Create a blob handle from B 4. close_v2 A 5. close_v2 B 6. close blob handle -> Segmentation fault The

Re: [sqlite] Bug in all-bnf.html documentation?

Fantastic, thank you! > On Jul 13, 2019, at 1:48 PM, Richard Hipp wrote: > > On 7/13/19, George King wrote: >> Is there any written description of the Sqlite grammar or is it >> now only described by the images? If nothing else, I'd be interested to peek >> at any sort of grammar

Re: [sqlite] Bug in all-bnf.html documentation?

On 7/13/19, George King wrote: > Is there any written description of the Sqlite grammar or is it > now only described by the images? If nothing else, I'd be interested to peek > at any sort of grammar representation in the source code. The images are the definitive description of the language.

Re: [sqlite] Bug in all-bnf.html documentation?

Thank you. Is there any written description of the Sqlite grammar or is it now only described by the images? If nothing else, I'd be interested to peek at any sort of grammar representation in the source code. > On Jul 13, 2019, at 12:28 PM, Richard Hipp wrote: > > On 7/13/19, George King

Re: [sqlite] Bug in all-bnf.html documentation?

On 7/13/19, George King wrote: > I found > the all-bnf.html page after a quick google search. That file is obsolete cruft in the Fossil repository that hosts the SQLite documentation. The BNF representation has not been supported for years. Shane added that support for us almost 10 years ago,

[sqlite] Bug in all-bnf.html documentation?

Hello, I'm writing to report an apparent error in the Sqlite documentation. I found the all-bnf.html page after a quick google search. https://www.sqlite.org/docsrc/doc/trunk/art/syntax/all-bnf.html It appears that the page is

Re: [sqlite] Bug in sqlite3.c

I tried "INSERT INTO ft(ft) VALUES('integrity-check')" and it also did not give any error. But the rebuild command helped solve my problem as the crashes stopped, otherwise my application was crashing at every commit operation (thanks a lot for that). Is there any command/API which can bypass

Re: [sqlite] Bug in sqlite3.c

On 4/6/62 12:11, bhandari_nikhil wrote: Thanks Dan. I had checked the database integrity using the following command: sqlite3 myfile.db "PRAGMA integrity_check;" Try "INSERT INTO ft(ft) VALUES('integrity-check')", where "ft" is the name of the fts5 table. And it had reported ok. I will

Re: [sqlite] Bug in sqlite3.c

Thanks Dan. I had checked the database integrity using the following command: sqlite3 myfile.db "PRAGMA integrity_check;" And it had reported ok. I will see if I can share the database file here. Can you let me know how to check the db file (in case I am not able to share the db file here) ? And

Re: [sqlite] Bug in sqlite3.c

On 3/6/62 12:51, bhandari_nikhil wrote: I am facing a crash in sqlite3fts5BufferAppendBlob. Following is the backtrace: #0 sqlite3Fts5BufferAppendBlob (pRc=pRc@entry=0xf54139c8, pBuf=pBuf@entry=0xf5afeb90, nData=4294967295, pData=0xf49fff76 "90246ture") at sqlite3.c:180474 #1 0xf717b6f8

[sqlite] Bug in sqlite3.c

I am facing a crash in sqlite3fts5BufferAppendBlob. Following is the backtrace: #0 sqlite3Fts5BufferAppendBlob (pRc=pRc@entry=0xf54139c8, pBuf=pBuf@entry=0xf5afeb90, nData=4294967295, pData=0xf49fff76 "90246ture") at sqlite3.c:180474 #1 0xf717b6f8 in fts5WriteAppendTerm

Re: [sqlite] Bug in sqlite: "View with UNION ALL and limit in subquery" (v 3.28.0)

Thank you for the report. The problem is now fixed on trunk. Ticket: https://www.sqlite.org/src/info/c41afac34f15781f Fix: https://www.sqlite.org/src/info/523b42371122d9e1 On 5/29/19, Marco Foit wrote: > Dear SQLite Developers, > > I just noticed the following bug in SQLite version 3.28.0: > >

[sqlite] Bug in sqlite: "View with UNION ALL and limit in subquery" (v 3.28.0)

Dear SQLite Developers, I just noticed the following bug in SQLite version 3.28.0: create table t AS values (1), (2); .print "select with correct output ..." select * from ( select * from t limit 1 ) union all select * from t ; .print "same select leads to incorrect result when used inside

Re: [sqlite] bug in sqlite3??

Let's not forget that the size of the database is going to grow above and beyond the "number of rows" due to pages that aren't reserved for your data, such index pages, etc. On Tue, May 28, 2019 at 1:49 PM Jens Alfke wrote: > > > > On May 26, 2019, at 7:21 PM, John Brigham wrote: > > > > The

Re: [sqlite] bug in sqlite3??

On 28 May 2019, at 6:49pm, Jens Alfke wrote: > Try opening a copy of the database with the `sqlite3` CLI tool and entering > “PRAGMA vacuum;”. Then exit and look at the file size. Alternatively use the sqlite3_analyze tool and read the "Pages on the freelist" figures.

  1   2   3   4   5   6   7   8   9   10   >