Re: [sqlite] without rowid and secondary indexes

Thanks! > In your example below, your PRIMARY KEY consists of two integer > instead of just a single rowid integer. So it will take up slightly > more space. Not a lot, but some. > > Will that make a difference in your application? I do not know. Then, I will indeed run some more tests, but

Re: [sqlite] UPPER function depends on Locale?

On 10 Apr 2018, at 7:44am, Dr. Mucibirahman İLBUĞA wrote: > I my opinion, there should be well documented, step by step information about > how to add ICU support in SQLite. I think that the reason this doesn't exist is that different people want to use different

Re: [sqlite] In memory only WAL file

I understand that the SQLite tells the OS all the correct things, but as I described earlier, that may just produce way too much IOPS, even if everything in the chain does the correct thing down to the last silicon transistor. That is why I was asking about a way how to go around it by holding

Re: [sqlite] Build error in SQLite 3.18 if SQLITE_UNTESTABLE is defined

On 4/10/18, Priebe, Sebastian wrote: > this error still exists. > Please fix it. You still have not answered my question: Why do you want to make SQLite untestable? -- D. Richard Hipp d...@sqlite.org ___ sqlite-users

Re: [sqlite] Build error in SQLite 3.18 if SQLITE_UNTESTABLE is defined

Hello, this error still exists. Please fix it. Greetings Sebastian SII Technologies GmbH Geschäftsführer: Robert Bauer Sitz der Gesellschaft: 86167 Augsburg Registergericht: Amtsgericht Augsburg HRB 31802-Ursprüngliche Nachricht- Von: Priebe, Sebastian Gesendet: Montag, 24. April

Re: [sqlite] without rowid and secondary indexes

Every index is composed of the columns being indexed followed by the primary key of the table. In a regular ROWID table, the "primary key" is the rowid - an integer. In a WITHOUT ROWID table, the primary key is whatever you declare the PRIMARY KEY to be. So whether or not there is more overhead

Re: [sqlite] Build error in SQLite 3.18 if SQLITE_UNTESTABLE is defined

On 4/10/18, Priebe, Sebastian wrote: > Imho all available build configurations should build. Sorry to disappoint. There are lots of legacy compile-time options in SQLite that we do not verify. We have a small subset of compile-time options that we support. I

Re: [sqlite] Constraining FTS5 results based on offsets()

On 04/08/2018 02:00 PM, miroslav.marango...@outlook.com wrote: Hi, For my use case I need to index some texts, and I also need be able to assign attributes to sub-sequences/spans of tokens in the texts. I want to be able to search only for keywords/phrases that occur in spans with a certain

[sqlite] without rowid and secondary indexes

Dear all, With https://www.sqlite.org/withoutrowid.html in mind, assuming something simple as: create table if not exists SHEETS( NODE integer not null, SHEET integer not null, NAME text, -- often NULL, sometimes short text value (keyword) ..., -- 2

Re: [sqlite] Build error in SQLite 3.18 if SQLITE_UNTESTABLE is defined

> You still have not answered my question: Why do you want to make SQLite > untestable? Because we don't want the extra code to make it testable in our project. Imho all available build configurations should build. SII Technologies GmbH Geschäftsführer: Robert Bauer Sitz der Gesellschaft:

Re: [sqlite] without rowid and secondary indexes

Olivier Mascia wrote: > [...] > So I should probably even better go with: > > create index ... where NAME is not NULL; > > as my only queries involving NAME have a 'where NAME is not NULL' restriction. To be sure, check with EXPLAIN QUERY PLAN whether the index is actually used. > select

[sqlite] Unexpected change of query behaviour due to optimization in 2.23.0

Hello, the recently-introduced change "The LEFT JOIN Strength Reduction Optimization"[1] lead to a critical change in the behaviour of a very simple query in our application. The query involves two tables, "pretixbase_cartposition" and "pretixbase_voucher". Both tables have a primary key called

Re: [sqlite] Unexpected change of query behaviour due to optimization in 2.23.0

Am Tue, 10 Apr 2018 12:55:13 +0200 schrieb Raphael Michel : > However, if I'm not mistaking, what I'm experiencing here is not a > false negative (optimizer not optimizing although possible) but a > false negative (optimizer optimizing although not possible). Errata: Of

Re: [sqlite] An artificial query whose outcome is changed after left join reduction

From your output: .version SQLite 3.23.0 2018-03-24 13:24:02 cf171abe954a5f25262161dd69f2e8cecdbf9446c3f6b298201507dbc743567e zlib version 1.2.3 gcc-4.0.1 (Apple Inc. build 5465) The release date of 3.23.0 was April 2nd. So are you using in-testing code rather than the full release?

Re: [sqlite] An artificial query whose outcome is changed after left join reduction

On 4/10/18, E.Pasma wrote: > Hello, the nature of this case is purely artificial and I thought it > is worth considering in the light of real world problem as reported by > Raphael Michel. E Pasma > > .version > SQLite 3.23.0 2018-03-24 13:24:02 >

Re: [sqlite] without rowid and secondary indexes

> Le 10 avr. 2018 à 13:20, Clemens Ladisch a écrit : > >> select NAME,count(NAME) from SHEETS group by NAME having SHEET>? and NAME is >> not NULL; > > The SHEET value is from some random row in the group, and the NAME value is > the same for all rows in the group. Are you

Re: [sqlite] An artificial query whose outcome is changed after left join reduction

That's weird. My compiled CLI for 3.23 gets what you're showing for 3.22 SQLite version 3.23.0 2018-04-02 11:04:16 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> .version SQLite 3.23.0 2018-04-02

[sqlite] An artificial query whose outcome is changed after left join reduction

Hello, the nature of this case is purely artificial and I thought it is worth considering in the light of real world problem as reported by Raphael Michel. E Pasma .version SQLite 3.23.0 2018-03-24 13:24:02 cf171abe954a5f25262161dd69f2e8cecdbf9446c3f6b298201507dbc743567e zlib version

Re: [sqlite] without rowid and secondary indexes

Olivier Mascia wrote: >> Le 10 avr. 2018 à 13:20, Clemens Ladisch a écrit : >>> select NAME,count(NAME) from SHEETS group by NAME having SHEET>? and NAME >>> is not NULL; >> >> The SHEET value is from some random row in the group, and the NAME value is >> the same for all

Re: [sqlite] An artificial query whose outcome is changed after left join reduction

Off-topic addendum minor typo: "They both store content has a sequence" in the first paragraph should be "as". Sent from my Samsung Galaxy S7 - powered by Three Original message From: Richard Hipp Date: 10/04/2018 15:50 (GMT+00:00) To: SQLite mailing list

Re: [sqlite] without rowid and secondary indexes

> Le 10 avr. 2018 à 18:25, Clemens Ladisch a écrit : > > Olivier Mascia wrote: >> Would you mean: >> >> select NAME,count(NAME) from SHEETS where SHEET>? group by NAME having NAME >> is not NULL; >> >> is more logically appropriate? > > Probably. The first query can

[sqlite] Internal Logic Error

While watching the value of Err.LastDllError, as soon as the single line in the function below is executed, the value becomes 2. According to my documentation, this value indicates an "Internal Logic Error". As this is a direct call to the SQLite DLL library, I am at loss as to the cause of

Re: [sqlite] To use or not to use single quotes with integers

Thanks Simon and David for your attention, Markos Insert the usual "Bobby Tables" reply here https://xkcd.com/327/ You really want to

Re: [sqlite] [EXTERNAL] Re: UPPER function depends on Locale?

But there already is a step by step instruction document right here http://sqlite.org/loadext.html that tells you exactly how to build a loadable extension, which can contain user defined functions, complete with references to examples. I suggest you use compress.c as a template, as this has

Re: [sqlite] [EXTERNAL] Re: UPPER function depends on Locale?

10.04.2018 11:18 tarihinde Hick Gunter yazdı: But there already is a step by step instruction document right herehttp://sqlite.org/loadext.html that tells you exactly how to build a loadable extension, which can contain user defined functions, complete with references to examples. I suggest

Re: [sqlite] UPPER function depends on Locale?

Dr. Mucibirahman İLBUĞA wrote > And I really shocked that am I first person on over the world who wants to > use SQLite in their own language?... :) You are not the first person that uses SQLite with a different character set than ASCII and with a different locale other than English US. If you

Re: [sqlite] UPPER function depends on Locale?

10.04.2018 10:30 tarihinde sandu yazdı: As Simon Slavin wrote, maybe in your case would be much easier to have dedicated lower/upper functions instead of recompiling with ICU option, if this is two complex for you. Hi, Yes. You and Simon are right. But in this case there is not any step by

Re: [sqlite] UPPER function depends on Locale?

09.04.2018 23:18 tarihinde sandu yazdı: The example you found is not applicable in your case, because it is describing an way to develop your own functions in PHP, which is not the case for you. Dear Buraga SANDU, Thanks alot for your kind interest. I my opinion, there should be well