Indeterminacy in SQL

Some SQL expressions are actually not function invocations at all in the mathematical sense, being indeterminate-invocations operating on identical input do not always yield the same value. The indeterminate expressions are among those that the standard defines as possibly non-deterministic, but- caveat lector-not all expressions defined as possibly non-deterministic are actually indeterminate from a mathematical viewpoint. For example, the key word USER denotes the userid (officially, the authorization identifier) of the session in which an expression containing that key word is evaluated. Such an expression is defined as possibly non-deterministic by virtue of the appearance of USER, even though invocations in different sessions, in which USER stands for different userids, are clearly different invocations.

For a more general example, a user-defined function can be explicitly declared as either DETERMINISTIC or NOT DETERMINISTIC. In the latter case the "function" is flagged such that all invocations of it are treated as possibly non-deterministic. Regardless of the appropriateness of the term non-deterministic, there is a good reason for categorizing references to the current user (or, for another example, the current time) along with genuine cases of indeterminacy. It concerns constraint declarations. We clearly want to outlaw a constraint condition whose result, when evaluated, depends on the properties of the session in which, or on the time at which, the evaluation takes place. Of course we must also outlaw genuinely indeterminate conditions-a database might satisfy such a condition but later fail to satisfy it even though the database has not been updated in the meantime! The question then arises as to how it is possible for indeterminacy to arise: surely a computer program always gives the same result when invoked with the same input?