BTW, I might implement and contribute something like this. I'm free to contribute any changes to SQLite3 that I make. I'd need some guidance though. And what I cannot contribute is the high degree of testing that SQLite3 is known for.
The parsing aspect of database triggers is simple enough. But there's a lot of little details. The simplest way to avoid most of those details would be to pretend (but not document!) that database triggers are like INSTEAD OF INSERT triggers on a view named sqlite_<something_or_other>, so that the existing code infrastructure for ROW triggers can be used without modification. Then at the various events act as though an insert has been done into that view. This approach would also simplify much of the testing (since existing testing would already be reaching every branch in the ROW trigger code). Would such a contribution be welcomed? Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
