The generated keys implementation assumes that the parser throws an exception on SELECT queries, and would then proceed executing the query normally. Unfortunately the parser doesn't throw an exception on a SELECT, and instead it processes the query by appending `RETURNING` + all columns in the database (which seems to be another bug in and of itself).

There are currently no tests that check the assumption that SELECT is treated unmodified.

The generated keys implementation assumes that the parser throws an exception on SELECT queries, and would then proceed executing the query normally. Unfortunately the parser doesn't throw an exception on a SELECT, and instead it processes the query by appending `RETURNING` + all columns in the database (which seems to be another bug in and of itself).
There are currently no tests that check the assumption that SELECT is treated unmodified.
See http://stackoverflow.com/questions/29752184/query-error-using-firebird-rdbms-with-coldfusion-11

Errors during parsing are now checked, and if there have been parser errors, or if no table name was found, then the query is executed as if it isn't a generated keys query. This fixes this problem (and some related issues).

Mark Rotteveel added a comment - 27/Apr/15 02:34 PM On further examination the parser intentionally ignores parser errors so it only has to process the first part of the query, and doesn't need to process the full statement.

Removed check for parser errors, the grammar is incomplete, for example DELETE and UPDATE are only implemented sufficiently to obtain the table name. Now only absence of table name in the statement model is considered for treating it as invalid.