Thanks for the response, Joe.
Except for the part where you say "do not have to write with the full ANSI/ISO current SQL standard", I have to continue to respectfully disagree. As a bit of a sidebar, the term "thunk" reminds me of the noise that performance frequently makes when an ORM incorrectly creates "interface code". 😀
Consider the following post by Alexander Kuznetsov
Ignoring the fact that writing a loop in ORACLE is still worse than writing something set-based, that simple stored procedure epitomizes exactly what I'm talking about. To pass a parameter to a stored procedure, you have to have variables as arguments. Various engines make variable assignments using different methods and how the variables are declared and named are frequently quite different, as well. As Alex says in his short article, I'm pretty sure that even this simple stored procedure cannot be written to be portable even if you were to remove the need for any output.
Without getting into all the things that I (and I'm not alone here) necessarily need to do on a daily basis that wouldn't stand a chance of being ANSI/ISO compliant, which also means no chance of being portable, I don't even consider whether code is portable or not when I'm writing SQL. Rather, I exploit even proprietary functionality of whatever database engine I'm using.
If you think even simple code can be written to be truly portable without it being generated by the likes of an ORM, then correctly answer the simple questions posed in the following link. 😛
https://groups.google.com/forum/#!topic/fido7.rdbms.oracle/NRNrTf6p6rE
--Jeff Moden
Change is inevitable... Change for the better is not.