Saxon SQL Extension

Not available in SaxonCS.

The saxon-sql-10.#.jar file, distributed alongside the main JAR file, includes a set of XSLT extension instructions, and from Saxon 9.9 also a set of extension functions, providing access to SQL databases. The JAR must be added to the classpath when these extensions are used.

The extension instructions are not intended as being necessarily a production-quality piece of software (there are many limitations in the design), but more as an illustration of how extension instructions can be used to enhance the capability of the processor.

More recently, Saxon provides a set of extension functions providing similar capability in a cleaner way (this has become possible with the introduction of new features in XSLT 3.0, such as maps and arrays). New applications should use the SQL extension functions in preference.

The SQL extension instructions cannot be represented in SEF files, and any attempt to export a stylesheet using these instructions will fail. This is one reason for preferring the newer extension functions.

    A Warning about Side-Effects

    XSLT does not guarantee the order of execution of instructions. In principle, the sql:close instruction could be evaluated before the sql:query instruction, which would obviously be disastrous.

    In practice, Saxon's order of execution for XSLT instructions is reasonably predictable unless you use variables, or unless you invoke stylesheet functions from within an XPath expression. Using the SQL extension instructions within templates that are directly invoked is thus fairly safe, but it is not a good idea to invoke them as a side-effect of computing a variable or invoking a function. The exceptions are sql:connect and sql:query: if you use these instructions to evaluate the content of a variable, then they will of course be executed before any instruction that uses the value of the variable.

    A Warning about Security (SQL injection)

    The instructions in the SQL extension make no attempt to verify that the SQL being executed is correct and benign. No checks are made against injection attacks; indeed the sql:execute instruction explicitly allows any SQL statement to be executed.

    Therefore, the extension should be enabled only if (a) the stylesheet itself is trusted, and (b) any text inserted into the stylesheet to construct dynamic SQL statements is also trusted.