On 09/06/2013 10:19 PM, Marc L. Allen wrote:
MySQL also uses this implementation. They acknowledge that it is not SQL
compliant and that (I never thought of this), you cannot delete a record that
has a foreign key link to itself.
Postgres apparently has the ability to have deferred checking as of V9, but not
before then.
SQLite defers checking FK constraints until the end of
the statement (or the end of the transaction, for
DEFERRABLE INITIALLY DEFERRED constraints). They are the
exception though - all others (CHECK, UNIQUE etc.) are
checked as part of updating/deleting/inserting each row.
Dan.
Please see:
http://stackoverflow.com/questions/5014700/in-mysql-can-i-defer-referential-integrity-checks-until-commit
-----Original Message-----
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
On Behalf Of Richard Hipp
Sent: Friday, September 06, 2013 11:07 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] UPDATE question
On Fri, Sep 6, 2013 at 11:00 AM, Dominique Devienne <ddevie...@gmail.com>wrote:
Myself, if I'm "thinking in sets", all implementation details aside,
the UPDATE statement looks fine and correct, and I'd have expected
SQLite to support it.
But I'm just waiting to read Dr. Hipp's own read on this now. --DD
I'm busy with a different problem and don't have time to study your thread, so
I'm guessing at the answer:
The UPDATE statement in SQLite operates row-by-row. The effect of early row
updates might be visible in later row updates if you contrive a sufficiently
complex example. But you really have to go out of your way to do that. If a
constraint error happens, the entire UPDATE statement is rolled back (except if
OR FAIL is specified - see the docs).
Yes, I know this is not "relational". No, I do not intend to fix it.
-
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
This email and any attachments are only for use by the intended recipient(s)
and may contain legally privileged, confidential, proprietary or otherwise
private information. Any unauthorized use, reproduction, dissemination,
distribution or other disclosure of the contents of this e-mail or its
attachments is strictly prohibited. If you have received this email in error,
please notify the sender immediately and delete the original.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users