On 2/26/20, Simon Slavin <slav...@bigfraud.org> wrote: > > Backward compatibility ? Do you think anyone who used the word AFTER > really wants a BEFORE trigger ? More likely to be a bug they should know > about.
We have seen triggers like this in the wild, that work as intended. If we change it to throw an error, the applications that use these kinds of triggers will suddenly start failing. Some of them (no doubt) are unmaintained. The source code has gone missing for some of them, perhaps. That much breakage is not worth it. The issue arises from the forgiving nature of the SQLite parser. The parser is designed so that we can add new keywords to the language (for example: "GENERATED" and "ALWAYS" in the most recent release, in support of generated columns) without breaking legacy schemas that use those keywords as table or column names. Consider what happens in the example Dan provide: CREATE TRIGGER AFTER INSERT ON t1 BEGIN ... END; The parser is bebooping along, parsing tokens one by one. The first token is the keyword CREATE. The second token is the keyword TRIGGER. All good so far. The third token is the keyword AFTER. But the grammar does not recognize the keyword AFTER in that context, and so the parser converts it into an identifier with the value of "AFTER". That does work, and so the parse continues, using "AFTER" as the name of the trigger. That example is a little confusing. But what if, instead, the trigger has been this: CREATE TRIGGER generated INSERT ON t1 BEGIN ... END; With strict enforcement of keywords, this trigger would have worked fine for all versions of SQLite through 3.30.1 and then started failing in version 3.31.0, because it was in that release that GENERATED became a keyword. But with the "fallback" mechanism in SQLite, the trigger continues to work as it always has. That is why the mechanism exists - to prevent unnecessary breakage when new keywords are added to the language. There are literally millions of applications that use SQLite. Some fraction of those are unmaintained. And some additional fraction of those will break, probably to never work again, whenever we add a keyword, except for the keyword fallback mechanism. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users