On 28/08/2018 02:20, Dmitry Yemanov wrote: > 27.08.2018 20:10, Adriano dos Santos Fernandes wrote: >> >> the whole thing may execute repeated times > > Imagine selectable SP/UDR joined to a table. Depending on the plan, > SP/UDR may be executed once or multiple times. You have virtually no > control over this. If that SP/UDR has "side effects", you'll need to > deal with the consequences. I don't see much difference from the > "statement consistency issue" you mention. Of course, repeated > execution may be less/not expected in more straightforward execution > paths, but it doesn't mean it's absolutely impossible. > This is completely different.
For this discussion, let name SQL as (SELECT / UPDATE / INSERT / MERGE / UPDATE OR INSERT) and PSQL the others statements. SQL (even when embedded in a PSQL statement) is a declarative language. Programmer does not tell it each necessary pass to do an action, so engine is free to produce the result. We all known that a function used there may be evaluated in an undefined number of times. So it's clear that one should not call a function with side effects there. Some DBMS like Oracle prevents that function called in SQL writes to the database. We don't but that is still considered as an undefined behavior if one does. PSQL on the other hand is an imperative language. Programmer tell it how to do things and calling functions with side effects is completely ok and necessary. One does not expect that engine reorder and recalls a function. Oracle does not implement statement consistency only delimited to an SQL (instead PL/SQL) because its loose integration, but because it's completely nonsense to do the contrary. Yes, multiple SQL statements may read different data, but that is READ COMMITTED. What's being done here is equivalent to an CPU processor doing speculative instruction execution crossing IO boundaries. You don't want to see in your screen a thing happening that your program don't want to do but your CPU does, or to see it multiple times. This is nonsense and at the same time it documents that the old behavior is deprecated and could be removed in a future release. None of this was even discussed in details. The patch is initially described by Nikolay in 2014 with Vlad commenting "Comments in code is good but not enough to understand idea, rules and correctness of implementation". All of this was vaguely explained until I reviewed the final version of the code. A "statement-level consistency" is a thing, a top-level request restart is a completely different thing. Adriano ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
