Actually, the affinity is applied first, however --
c0 has affinity "A" (blob) applied.
c1 has affinity "E" (real) applied, but has the "tryForInteger" set which
results in an integer value
the GLOB function converts its arguments to text, so when it is presented with
the "integer" c1
Hi everyone,
It think that I found a bug where I could circumvent a UNIQUE check of an
index. Consider the example below, which causes "Error: UNIQUE constraint
failed" when invoking REINDEX:
CREATE TABLE test (c0, c1 REAL);
CREATE UNIQUE INDEX index_1 ON test(c0 GLOB c1);
INSERT INTO test(c0,
In date.c at line 83:
/*
** Convert zDate into one or more integers according to the conversion
** specifier zFormat.
**
** zFormat[] contains 4 characters for each integer converted, except for
** the last integer which is specified by three characters. The meaning
** of a four-character
Hi everyone,
the following sequence of SQL statements results in "Error: malformed
database schema (index_0) - non-deterministic functions prohibited in index
expressions".
CREATE TABLE test (c0);
CREATE INDEX index_0 ON test(c0 LIKE '');
PRAGMA case_sensitive_like=false;
VACUUM;
SELECT * from
Okay, thanks!
Best,
Manuel
Am So., 28. Apr. 2019 um 21:02 Uhr schrieb Simon Slavin <
slav...@bigfraud.org>:
> On 28 Apr 2019, at 7:58pm, Manuel Rigger wrote:
>
> > It seems that setting "PRAGMA case_sensitive_like" to either false (the
> default behavior) or true results in no longer being
Sorry to bother, Mohd. What is your use case? I mentioned this to
developers around me and they are intrigued. You are storing a database
file as blob in a database? We are curious as to the application. I am
assuming the database being stored is a collection of sensor or event data?
On Fri, Apr
AFAIK it is considered good practice to group fields used in indices at the
beginning of the table definition (because they tend to get referenced most)
and BLOB fields at the end (because acessing fields behind a BLOB - which is
"large" by definition - tends to take more effort).
So the
On 2019/04/30 2:10 AM, Deon Brewis wrote:
Given the SQL below, FooX is a covered index for x on Foo.
I want to create FooXB as a second index on x in Foo. Since 'x' is covered on
FooX it should be cheaper to build FooXB from index FooX, than from table Foo.
However, as far as I can tell from
Given the SQL below, FooX is a covered index for x on Foo.
I want to create FooXB as a second index on x in Foo. Since 'x' is covered on
FooX it should be cheaper to build FooXB from index FooX, than from table Foo.
However, as far as I can tell from the from the opcodes of the index creation
9 matches
Mail list logo
