Romulo Goncalves wrote:
Dear developers,
SQL with procedures (function...) can almost be considered a programming language so it is not our responsibility to kill loops created by users SQL code. If an user see a infinite loop he has to construct the schema in such way that the infinite loops are avoided.
Another point is the restriction that we created for recursive triggers (we only allow at least one call for each trigger in each statement execution) which I think it is not correct.
This is the DB2 semantics.
A lot of research went into triggers and semantics. Consensus was indeed that triggers are too much a programming feature, which allows upfront analysis limited and protection against 'loops' unavoidable. The advise is to only use triggers to update derived tables (e.g. warehouses)
Imagine that the user has an "if clause" to recursively fire a trigger 10 times and after that 10 times the trigger is not fired anymore. Should we restrict this example in our system? I do not think so. However, If the clause check is wrong and an infinite loop is created it is the user who has to correct his schema.
The big conclusion of the day is: More programing language features do we offer to the user less control we have over his SQL code.
If everyone agree I will close the bug infinite loop and remove the loop check for triggers.
Go ahead.