• . 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". BigGrin

    I am not really sure where the term "thunk" came from. I know that it first showed up in Algol 60 because it was the first language to interview various kinds of parameter passing. There was "call by name" and "call by value" and then we added, "call by reference" in PL/1 and finally call by need"

    >> Consider the following post by Alexander Kuznetsov

    http://sqlblog.com/blogs/alexander_kuznetsov/archive/2009/02/24/writing-ansi-standard-sql-is-not-practical.aspx <<

    I noticed that one of his commenters talked about having a dozen different databases and supporting with portable code. But I still think the best example is the TPC (transaction processing Council) test sets. They have to be ported from ANSI standard to quite a few target databases and the vendors are able to translate it in such a way that they get the best performance out of their products. It also been doing this for quite a few years, so we have a lot of evidence that it is quite that possible to get both portability and performance.

    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.

    Yet somehow DB2 version 11 is able to pass them around without any problems. Have you noticed vendors have been trying to get over to ANSI standards for years? This is why SQL Server now has DATE and DATETIME2(n) as a synonym for the ANSI standard TIMESTAMP(n).

    And why Oracle VARCHAR2(n) was added to that mess they sell as a database.

    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. [/QUOTE

    And this is where I make my living 🙂 a lot of my customers have gotten trapped in proprietary code, often on smaller SQL products like SQL Server, get successful, and have to move it to a mainframe or other platform; very often these days, several other platforms.

    Books in Celko Series for Morgan-Kaufmann Publishing
    Analytics and OLAP in SQL
    Data and Databases: Concepts in Practice
    Data, Measurements and Standards in SQL
    SQL for Smarties
    SQL Programming Style
    SQL Puzzles and Answers
    Thinking in Sets
    Trees and Hierarchies in SQL