Me too. Either as a new standard way of working, or as something
which can be turned on and off with a PRAGMA. I accept that SQLite is
meant to be fast, but having SQLite spit out which check was violated
will result in my app running faster and more dependably than when I
build the same logic into my own code.
I can only warmly agree to every "pro" reason exposed so far.
Not only that but even if that means a non-trivial code increase, I bet
my hat that once the feature is there, its code will be shortly
imperative in almost every serious use of SQLite.
I mean, even if such a safety net code portion clearly won't run as
often as b-tree scans, it will be there for applications to robustly
rely on it. This will only promote more systematic use of constraints
checks (that probably use much more code in SQLite core that this
feature) and greatly simplify [and debug] applications.
So this extra code, even if seldom actually run, will certainly become
very important to users, in my view more useful than native foreign
keys. (Not that I'd like DRH to remove native FK support)!
JcD
War does not determine who is right - only who is left.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
