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 PlayersFTS WHERE (PlayersFTS MATCH 'LastName:B') OR (PlayersFTS MATCH 'FirstNames:2');) > Am 2020-01-23 um 17:51 schrieb Jens Alfke : > > >> 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 has to be at top-level or > in an AND. > > —Jens > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Sqlite 3.31.0 breaks firefox and thunderbird
On Jan 23, 2020, at 8:33 AM, Bernhard Rosenkraenzer wrote: > > The Debian guys have also observed this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949644 > (and also don't have a fix yet). > > Any ideas? Can you bisect SQLite to narrow the range here? This release had an unusually long period to cook, so without a bisect, you’re kind of asking for someone to remember what they changed months ago. Method: 1. Check out SQLite source from Fossil: https://sqlite.org/src/ 2. fossil bisect reset ; fossil bisect bad (marks tip-of-trunk as “bad”) 3. fossil bisect good version-3.30.1 (or whatever version you last tested as “good”) At that point, the source tree will contain a version halfway between tip-of-trunk and the version you marked “good” with the third command. Build it, test it, then say either “fossil bisect bad” or “fossil bisect good” depending on whether it crashes again. By my count, there have been 551 checkins between those two releases, so a bisect should take roughly 9 tries to find the culprit: $ fossil timeline after version-3.30.1 -t ci -n 0 | grep -c '^[0-9]' ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
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 probably making the change to the wrong place in the code: you’re changing a generated file rather than a proper source file. Saying “fossil up” or “fossil up release” should merge your local edits into the new release automatically unless upstream changes something nearby or on those same lines. I don’t say this expecting that these problems will remain unfixed upstream, just as general forward-looking advice. Fossil can be a useful aide in carrying local changes from one release to the next. There are more advanced methods beyond that, such as private branches and autosync=0, but at that point we should take it up on the Fossil forum. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] New uuid extension in amalgamation
On Jan 23, 2020, at 5:45 AM, Dominique Devienne wrote:
>
> Hi. Looks like 3.31 (congrats on the release) does not include that
> small extension in the amalgamation. Could it please?
It’s easy to fix:
1. Get the SQLite source proper (https://sqlite.org/src/)
2. Add “uuid.c” to the loop currently beginning on line 293 in
tool/mksqlite3c.tcl. I suggest adding it down at the end where the rest of the
extensions are listed.
3. Add “ext/misc/uuid.c” to the SRC macro in Makefile.in.
4. “make”
Now you have a sqlite3.c with the local changes you prefer.
Here’s a patch to do it with either the current tip-of-trunk or with the
current “release” tagged version:
Index: Makefile.in
==
--- Makefile.in
+++ Makefile.in
@@ -362,10 +362,11 @@
SRC += \
$(TOP)/ext/rbu/sqlite3rbu.h \
$(TOP)/ext/rbu/sqlite3rbu.c
SRC += \
$(TOP)/ext/misc/json1.c \
+ $(TOP)/ext/misc/uuid.c \
$(TOP)/ext/misc/stmt.c
# Generated source code files
#
SRC += \
Index: tool/mksqlite3c.tcl
==
--- tool/mksqlite3c.tcl
+++ tool/mksqlite3c.tcl
@@ -401,10 +401,11 @@
dbstat.c
dbpage.c
sqlite3session.c
fts5.c
stmt.c
+ uuid.c
} {
copy_file tsrc/$file
}
# Synthesize an alternative sqlite3_sourceid() implementation that
The neat thing about this method is that a local patch like this can survive
subsequent upstream changes as long as upstream doesn’t modify the code near
these locations: just say “fossil update release” to upgrade to each subsequent
release version, and as long as Fossil doesn’t complain about a merge conflict,
the new release should build with your local change without complaint.
Speaking of build errors, though, I get this when doing the above on macOS
10.14:
sqlite3.c:228541:9: warning: implicitly declaring library function 'isxdigit'
with type 'int (int)' [-Wimplicit-function-declaration]
if( isxdigit(zStr[0]) && isxdigit(zStr[1]) ){
^
sqlite3.c:228541:9: note: include the header or explicitly provide a
declaration for ‘isxdigit'
It’s complaining about the call to isxdigit() in sqlite3UuidStrToBlob() within
the uuid.c file. Above that in the source file, there *is* an #include for
, but in the built amalgamation, it’s commented out. It looks like
the amalgamation build process is somehow “intelligently” deciding that this
file doesn’t really need to be included.
There is an include for this header higher up that looks like it could be
pressed into service:
#if !defined(SQLITE_ASCII) || \
(defined(SQLITE_ENABLE_FTS3) && defined(SQLITE_AMALGAMATION))
# include
#endif
I’m out of SQLite-fu to work out how to adjust the build system to do the right
thing here, short of brute force.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
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 has to be at top-level or in an AND. —Jens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Sqlite 3.31.0 breaks firefox and thunderbird
On 1/23/20, Bernhard Rosenkraenzer wrote: > Hi, > after updating sqlite to 3.31.0, both firefox and thunderbird crash on > startup (rebuilding them against the newer sqlite doesn't help). Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=1607902 > Backtrace: > (gdb) bt > #0 0x71b9fe20 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #1 0x71b993d2 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #2 0x7fffef3afdf5 in pagerOpenWal () from /usr/lib64/libsqlite3.so.0 > #3 0x7fffef398e76 in sqlite3BtreeBeginTrans () from > /usr/lib64/libsqlite3.so.0 > #4 0x7fffef3ed074 in sqlite3InitOne () from /usr/lib64/libsqlite3.so.0 > #5 0x7fffef3f105e in sqlite3Pragma () from /usr/lib64/libsqlite3.so.0 > #6 0x7fffef3b44ea in yy_reduce () from /usr/lib64/libsqlite3.so.0 > #7 0x7fffef397df0 in sqlite3RunParser () from > /usr/lib64/libsqlite3.so.0 > #8 0x7fffef3968a9 in sqlite3Prepare () from /usr/lib64/libsqlite3.so.0 > #9 0x7fffef396171 in sqlite3LockAndPrepare () from > /usr/lib64/libsqlite3.so.0 > #10 0x7fffef3881cf in sqlite3_exec () from /usr/lib64/libsqlite3.so.0 > #11 0x71b93ddc in ?? () from /usr/lib64/firefox-71.0/libxul.so > #12 0x71b934a4 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #13 0x71b938eb in ?? () from /usr/lib64/firefox-71.0/libxul.so > #14 0x71ba2be2 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #15 0x71626619 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #16 0x716347b8 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #17 0x71530f1f in ?? () from /usr/lib64/firefox-71.0/libxul.so > #18 0x71533006 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #19 0x718a5dca in ?? () from /usr/lib64/firefox-71.0/libxul.so > #20 0x718757b8 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #21 0x7152f0b5 in ?? () from /usr/lib64/firefox-71.0/libxul.so > #22 0x777f6979 in ?? () from /lib64/libnspr4.so > #23 0x77f8a031 in start_thread () from /lib64/libpthread.so.0 > #24 0x77b6f4df in clone () from /lib64/libc.so.6 > > The Debian guys have also observed this: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949644 > (and also don't have a fix yet). > > Any ideas? > > Best regards > bero > > ___ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Sqlite 3.31.0 breaks firefox and thunderbird
Hi, after updating sqlite to 3.31.0, both firefox and thunderbird crash on startup (rebuilding them against the newer sqlite doesn't help). Backtrace: (gdb) bt #0 0x71b9fe20 in ?? () from /usr/lib64/firefox-71.0/libxul.so #1 0x71b993d2 in ?? () from /usr/lib64/firefox-71.0/libxul.so #2 0x7fffef3afdf5 in pagerOpenWal () from /usr/lib64/libsqlite3.so.0 #3 0x7fffef398e76 in sqlite3BtreeBeginTrans () from /usr/lib64/libsqlite3.so.0 #4 0x7fffef3ed074 in sqlite3InitOne () from /usr/lib64/libsqlite3.so.0 #5 0x7fffef3f105e in sqlite3Pragma () from /usr/lib64/libsqlite3.so.0 #6 0x7fffef3b44ea in yy_reduce () from /usr/lib64/libsqlite3.so.0 #7 0x7fffef397df0 in sqlite3RunParser () from /usr/lib64/libsqlite3.so.0 #8 0x7fffef3968a9 in sqlite3Prepare () from /usr/lib64/libsqlite3.so.0 #9 0x7fffef396171 in sqlite3LockAndPrepare () from /usr/lib64/libsqlite3.so.0 #10 0x7fffef3881cf in sqlite3_exec () from /usr/lib64/libsqlite3.so.0 #11 0x71b93ddc in ?? () from /usr/lib64/firefox-71.0/libxul.so #12 0x71b934a4 in ?? () from /usr/lib64/firefox-71.0/libxul.so #13 0x71b938eb in ?? () from /usr/lib64/firefox-71.0/libxul.so #14 0x71ba2be2 in ?? () from /usr/lib64/firefox-71.0/libxul.so #15 0x71626619 in ?? () from /usr/lib64/firefox-71.0/libxul.so #16 0x716347b8 in ?? () from /usr/lib64/firefox-71.0/libxul.so #17 0x71530f1f in ?? () from /usr/lib64/firefox-71.0/libxul.so #18 0x71533006 in ?? () from /usr/lib64/firefox-71.0/libxul.so #19 0x718a5dca in ?? () from /usr/lib64/firefox-71.0/libxul.so #20 0x718757b8 in ?? () from /usr/lib64/firefox-71.0/libxul.so #21 0x7152f0b5 in ?? () from /usr/lib64/firefox-71.0/libxul.so #22 0x777f6979 in ?? () from /lib64/libnspr4.so #23 0x77f8a031 in start_thread () from /lib64/libpthread.so.0 #24 0x77b6f4df in clone () from /lib64/libc.so.6 The Debian guys have also observed this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949644 (and also don't have a fix yet). Any ideas? Best regards bero ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[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'); INSERT INTO PlayersFTS (rowid,LastName,FirstNames) VALUES(2,'B','2'); The following SELECT statement fails with the error "unable to use function MATCH in the requested context": SELECT Games.* FROM Games,PlayersFTS WHERE ((PlayersFTS.rowid=Games.BlackID)OR(PlayersFTS.rowid=Games.WhiteID))AND(PlayersFTS MATCH 'LastName:A'); This SELECT statement works: SELECT Games.* FROM Games,PlayersFTS WHERE (PlayersFTS.rowid IN(Games.BlackID,Games.WhiteID))AND(PlayersFTS MATCH 'LastName:A'); Regards, Hartwig ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
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 version takes a grand total of about 2 seconds, but it would be nice not to have to remember to do it every time :) -- Sent from: http://sqlite.1065341.n5.nabble.com/ ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
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-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[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 null pointer
"zPath" to "strlen", which dereferences it.
# 5697| if( zFree==0 ){ rc = SQLITE_NOMEM; }
# 5698| zPath = (const char*)zFree;
# 5699|-> nPath = (int)strlen(zPath);
# 5700| }
# 5701| }
It sais that ZPath can be NULL during strlen() action. I have made a patch,
which seems to solve this issue. Can you please confirm or discomfirm my
cheanges?
diff --git a/ext/misc/zipfile.c b/ext/misc/zipfile.c
index e6141ef..1f214a4 100644
--- a/ext/misc/zipfile.c
+++ b/ext/misc/zipfile.c
@@ -1630,9 +1630,12 @@ static int zipfileUpdate(
** otherwise. */
if( zPath[nPath-1]!='/' ){
zFree = sqlite3_mprintf("%s/", zPath);
- if( zFree==0 ){ rc = SQLITE_NOMEM; }
- zPath = (const char*)zFree;
- nPath = (int)strlen(zPath);
+ if( zFree==0 ){
+ rc = SQLITE_NOMEM;
+ } else {
+ zPath = (const char*)zFree;
+ nPath = (int)strlen(zPath);
+ }
}
}
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] New uuid extension in amalgamation
Hi. Looks like 3.31 (congrats on the release) does not include that small extension in the amalgamation. Could it please? Uuids are fairly common in many schemas, so native support "by default" would standardize support for them in the SQLite ecosystem. Thanks, --DD PS: And we'd be able to retire our own functions, which are inconveniently not available from the SQLite shell unless explicitly loaded from our custom extension lib. ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
