>> Table of Contents >> Article


This section defines the syntax of all elements required to declare user defined functions, which are to be used within the context of the database. Functions consist of signature information and implementation. Note: While the function's signature should be portable among several DBMS, the implementation may be not.

Element function

  ELEMENT function (description?, implementation+)
       name        string
       title       string
Attributes Type Mandatory Default Description
name string yes n/a Name of the function. It should be lowercased and a valid XML and SQL identifier.
title string - n/a The title is a label text that should be displayed in the documentation of this object.

A user defined function with the given name. The function may have at most one implementation for each supported DBMS.

Element implemetation

  ELEMENT implementation (param*, return?, code)
       dbms        string
       language    string
Attributes Type Mandatory Default Description
dbms string - generic The name of the target DBMS. The value "generic" means that the definition is suitable for any DBMS. Usually this is used as a fall-back option for DBMS you haven't thought of when creating the database structure or for those that simply doesn't have the feature in question.
language string - n/a The target programming language. This applies only to DBMS, that support more then one language.

The implementation defines the function signature and source code. The number of parameters must be the same for each DBMS (and implementation tag).


If the attribute dbms is set to "generic", the XDDL-implementation may decide if the generic function definition is compatible with a certain DBMS. If it decides that the definition is not compatible, it may try to simulate the function. In that case the implementation may define the required syntax for the values of it's child elements "code", "param" and "return". If the definition does not match the required syntax, the XDDL-implementation may throw an error.

Note that the attribute "language" is DBMS-dependent. Most DBMS should at least support the value "SQL" as a language, while others may also include "Java", "C++" or more.
If no language is given, the default language is used. Note that this implementation may not check if the given language is really supported by the given DBMS.

For simulated functions the language attribute must be blank.

Element param

       name     string
       type     string
       mode     string
Attributes Type Mandatory Default Description
name string yes n/a unique parameter name
type string yes n/a DBMS-dependent data type
mode string - in The attribute "mode" identifies the element as
input-parameter (call by value)
output-parameter (call by reference)
reference-parameter (call by reference)

A parameter definition as part of the function signature. The attribute "mode" identifies the behavior of the parameter. The type of the parameter is DBMS-dependent.


  <function name="foo">
      <param name="p1" type="string" mode="in"/>
      <param name="p2" type="float" mode="inout"/>
      <param name="p3" type="int" mode="out"/>

  May be interpreted as:

  int foo ( string $p1,  float &$p2,  int &$p3 = null ) { ... }

Note that some DBMS only support input parameters (call by value). In that case the attribute "mode" must have the value "in". The implementation may throw an error if an unsupported definition is found.

Element return

  ELEMENT return (#PCDATA)

The data type returned by the function. This setting is DBMS-dependent.

If no return element is defined, or if it is left empty, the return type defaults to "void", which means, the function doesn't return a value. If the function needs to return more then one value, it should use output-parameters instead. Be aware that in MySQL functions without a return value are called "methods".

Element code


The function body. The syntax of the content depends on the attributes for DBMS and programming language. If the DBMS is set to "generic", then this code is executed by the server application. In that case the implementation may define the required syntax itself. It is recommended, to limit the code to being the name of a function, that the implementation may call. All input parameters must be redirected to that function. Note that generic functions can't be used inside SQL-statements as these are not executed by the DBMS.

Author: Thomas Meyer, www.yanaframework.net