On 20 Oct 2013, at 3:34am, Bogdan Ureche <bogdan...@gmail.com> wrote:
> Thank you for replying and for updating the documentation. I didn't realize > that the trigger may be unexpectedly reattached to a different table when > the schema changes. If this is the case then perhaps the creation of temp > triggers on non-temp tables using non-qualified table names should not be > allowed. Maybe this will be corrected in SQLite4? The problem is not that table names aren't qualified. The problem is that information for setting up the schema (structural components) of a SQLite database are stored in the database as the SQL commands rather than a complicated internal format. This makes it permissable to do this: 1. set up a trigger that refers to a table called 'books' 2. use that trigger a number of times 3. delete the table 'books' 4. create a new table 'books' 5. use that trigger more times. An iron-bound high-end SQL implementation would prevent step 3 from happening with an error message. >> Who are your users that you allow them arbitrary control over the DDL and >> yet you feel the need to protect them from their own actions? > > This is not about protecting users from their own actions, but rather about > providing them correct feedback as a result of these actions. You have identified SQLite's achilles heel. It is not possible to interrogate a SQLite database file and figure out everything about it using just the SQLite API. You either have to write a SQL parser or set up traps on the parts of SQLite to see what they're doing. The result is a very fast, very small, very convenient SQL engine, but one which cannot be nailed down in the way you want. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
