Server-side XSQL scripts can now declare integer array variables and iterate over them with two new constructs: <for list> for ordered sequential iteration and <forall> for set-based iteration where element order is immaterial. Both constructs operate without a database roundtrip — the list is held in script memory and iteration is driven by the XSQL runtime — producing the same behaviour regardless of which of the seven supported OLTP engines is active on the connection.
Variable and iteration syntax
- Integer array variable. Declaring
<variable type="integer[]">allocates an in-memory integer list within the script scope. Values are populated through parameter binding on entry or through assignment within the script body; the list is not written to any database table. - for list iteration.
<for list>traverses the array in declaration order, binding the current element to a named variable inside the iteration body. The body can execute any XSQL statement — queries, DML, nested loops — against the active connection. - forall iteration.
<forall>applies a statement block to all elements without guaranteeing processing order. It is the correct form for batch operations where each element is independent and the script does not depend on sequence.
Why cross-database list iteration matters
- Portability across engines. SQL array syntax and bulk-bind constructs differ significantly between the supported engines.
<for list>and<forall>express the intent once and the XSQL runtime translates it, removing engine-specific workarounds from business logic scripts. - No temporary tables required. Passing a list of identifiers into a script previously required a temporary table or a comma-delimited string parsed with engine-specific SQL. Integer array variables eliminate both approaches for the integer case.
- Parameter-driven batch operations. A caller can pass a list of record identifiers as the array parameter; the script iterates and processes each record within the same transaction without constructing a dynamic
INclause.
The constructs are available in all contexts that accept XSQL scripts: REST endpoint handlers, scheduled job definitions, and application event scripts. Existing scripts that used temporary-table or string-splitting patterns for list iteration continue to work without modification; refactoring to the new constructs is optional.