On 22 Sep 2009, at 9:45pm, D. Richard Hipp wrote: > The question is this: Should the no-op UPDATE statement (x=x) cause > the ON UPDATE SET NULL foreign key constraint to set t2.y to NULL or > not?
You would surely need agreement with the result of sqlite3_changes(), right ? CREATE TABLE fred (a INT, b TEXT); INSERT INTO "fred" VALUES(1,'fred'); INSERT INTO "fred" VALUES(2,'june'); INSERT INTO "fred" VALUES(3,'june'); INSERT INTO "fred" VALUES(4,'may'); PRAGMA count_changes = YES; sqlite> UPDATE fred SET b='june' WHERE b='june'; 2 sqlite> UPDATE fred SET a=a WHERE b='june'; 2 Similarly, from your own code (just in case 'REFERENCES' did something strange): sqlite> UPDATE t1 SET x=x; 1 In SQLite the change count corresponds to the number of rows which qualify for the WHERE clause, not the number of rows which have values which actually changed. Is this somehow specified by an SQL standard, or was it a design-choice for SQLite ? Either way, if you noted that two rows were changed, I would guess that anything that results from a change to a row should apply to those rows. This is also more flexible because if you want the other behaviour you can do something like UPDATE t1 SET x=x WHERE x!=x; > And a related question: Does anybody really care about ON UPDATE SET > NULL? Has anybody ever actually seen ON UPDATE SET NULL used in > practice? Not me, but I think I've only ever used ON UPDATE once. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
