Control / params · All operations

Pass parameters to a query

A variant of Set parameters

Write a query with placeholders and supply their values when it runs.

Status

In arcform

Not built yet

arcform does not do this yet; it would live in how a Protocol runs. Its place on the roadmap

What other tools call it

Meridian's classification; an independent blind rating agreed on 95.7% of 324 rows (variant, version 3).

Apache DataFusion (1)
  • PREPAREread 2026-09-27

    Store a statement with placeholder arguments for repeated execution

DuckDB (3)
Ibis (2)
  • Argumentread 2026-09-27

    Named, typed placeholder for a lambda or deferred-function argument

  • ScalarParameterread 2026-09-27

    Typed placeholder whose value is supplied when the query is executed

Background

A prepared statement is a database feature that pre-compiles SQL code and stores the result, separating the code from the data.[1] In a prepared statement, values left unspecified are called parameters, placeholders or bind variables, and are supplied when the statement runs.[1] SQL injection is a code injection technique in which malicious SQL statements are inserted into an entry field for execution.[2] Prepared statements offer security by reducing or eliminating SQL injection attacks.[1]

When to use it

Prepared statements can be used repeatedly without re-compiling, and an application may execute one many times with different values.[1]

The alternative to a prepared statement is calling SQL directly in a way that combines code and data, with the values written into the statement text.[1] Pass a value as a parameter whenever it came from outside the query, from a user, a file or another step, and build the text of a query only from names you control. (Meridian's view)

The method

A common prepared-statement workflow prepares a template with parameters, has the database compile and store it without executing it, then executes it with values bound to the parameters.[1] In DuckDB, PREPARE creates a prepared statement, EXECUTE runs it with optional arguments, and DEALLOCATE removes it.[3] DuckDB has three syntaxes for parameters in prepared statements: auto-incremented (?), positional ($1) and named ($param).[4] Not all DuckDB clients support all three parameter syntaxes: DuckDB's JDBC client for Java supports only auto-incremented parameters in prepared statements.[4]

In DuckDB 2.0, a named parameter that is not supplied at execution time is filled from the session variable of the same name, and an explicit argument always takes precedence.[4] In DuckDB, the fallback to session variables applies to named parameters only, and auto-incremented and positional parameters are never filled from one.[4]

Compared with the alternatives

A stored procedure is also precompiled and stored on the server, but a prepared statement, unlike one, is not normally written in a procedural language and cannot use variables or control flow structures.[1]

Sources

  1. [1]Prepared statementsecondary source
  2. [2]SQL injectionsecondary source
  3. [3]PREPARE, EXECUTE, and DEALLOCATE Statements – DuckDBdocumentation
  4. [4]Prepared Statements – DuckDBdocumentation