package libsqlite3-0
severity 500792 normal
thanks
Hi Tristan!
On Wed, 2008-10-01 at 15:30 +0200, Tristan Seligmann wrote:
> The following series of statements produces incorrect results in version
> 3.5.9 of sqlite:
> CREATE TABLE foo(foo TEXT);
> INSERT INTO foo VALUES ('a');
> INSERT INTO foo VALUES ('b');
> CREATE INDEX foo_foo ON foo(foo);
> SELECT DISTINCT foo FROM foo WHERE foo IS NOT NULL;
Please note that you name everything as foo.
> [EMAIL PROTECTED]:~> sqlite3 < ~/foo.sql
> b
I'm sure sqlite3 just gets confused what do you mean on foo with
v3.5.9 . I can't reproduce it on the same architecture with the same
version if I try it as:
CREATE TABLE store(col TEXT);
INSERT INTO store VALUES('a');
INSERT INTO store VALUES('b');
SELECT DISTINCT col FROM store WHERE col IS NOT NULL;
It gives the expected result.
> The underlying table is unaffected, so there is no direct data loss, but
> implicit data loss may occur as a result of applications receiving
> incomplete data in response to their queries, so I believe the grave
> severity is justified.
I don't think real world applications use the same name for table and
column names. While this problem is real, it affects only badly named
tables and columns. Reducing its severity to normal.
Upstream released v3.6.2, but I wait with packaging it until Lenny gets
hard-frozen.
Regards,
Laszlo/GCS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
