On 2013.10.15 10:34 PM, Petite Abeille wrote:
On Oct 16, 2013, at 7:20 AM, Darren Duncan <dar...@darrenduncan.net> wrote:
On 2013.10.14 11:58 PM, Sqlite Dog wrote:
seems like SQLite is not checking trigger SQL for invalid column names
until execution?
What you describe sounds like the behavior of every SQL DBMS which has triggers
whose trigger behavior I know.
Hmmm… FWIW… Oracle, for one, will invalidate triggers, views, packages, etc if
their underlying tables change.
There is even a very handy ALL_DEPENDENCIES views to track all the explicit
interdependencies between objects:
http://docs.oracle.com/cd/B28359_01/server.111/b28320/statviews_1066.htm#i1576452
But the key thing here, and my point, is that even Oracle wouldn't block the
underlying tables change due to the invalidation of other schema objects that
would result.
Oracle would allow the invalid trigger/view/package definitions to exist, rather
than requiring the user to temporarily delete those first or update their
definitions simultaneously with the underlying tables thereby enforcing
compatibility.
This is what I'm talking about, that invalid trigger/etc definitions are allowed
to exist, by every SQL DBMS whose behavior I know about, and SQLite matching
that behavior would best be maintained.
Not checking trigger/etc validity until execution makes it possible to
separately change the tables and other objects depending on them, or for that
matter, altering underlying tables again to bring them back into compatibility
with other objects' expectations of them, at which point the triggers/etc would
become valid again without having ever changed.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
