PostgreSQL wiki - User contributions [en]

Implementation of declarative catalog session variables

2026-01-01T07:50:21Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, sql plus, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)
** Inside only PL (Oracle)
** Inside db engine (MySQL, T-SQL, DB2)

Another classification:
* external (are not part of SQL)
** server side (Oracle package variables - part of PL for stored procedures (PL/SQL))
** client side (psql, sql plus)
* native (are part of SQL)
** persistent (DB2)
** declarative (T-SQL)
** implicit (MySQL)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL), and cannot be declared outside routines. The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PL/pgSQL has not own data types, own operators library (language library), own dependency tracking. This is main difference from PL/SQL. PL/pgSQL is just very simple interpret that fully use types, functions, operators, dependency tracking implemented by Postgres for SQL support. Is not possible to implement variables with larger scope than transactions without Postgres dependency tracking.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2026-01-01T07:40:51Z

Okbobcz: /* SQL/PSM */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, sql plus, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)
** Inside only PL (Oracle)
** Inside db engine (MySQL, T-SQL, DB2)

Another classification:
* external (are not part of SQL)
** server side (Oracle package variables)
** client side (psql, sql plus)
* native (are part of SQL)
** persistent (DB2)
** declarative (T-SQL)
** implicit (MySQL)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL), and cannot be declared outside routines. The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PL/pgSQL has not own data types, own operators library (language library), own dependency tracking. This is main difference from PL/SQL. PL/pgSQL is just very simple interpret that fully use types, functions, operators, dependency tracking implemented by Postgres for SQL support. Is not possible to implement variables with larger scope than transactions without Postgres dependency tracking.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2026-01-01T07:38:08Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, sql plus, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)
** Inside only PL (Oracle)
** Inside db engine (MySQL, T-SQL, DB2)

Another classification:
* external (are not part of SQL)
** server side (Oracle package variables)
** client side (psql, sql plus)
* native (are part of SQL)
** persistent (DB2)
** declarative (T-SQL)
** implicit (MySQL)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PL/pgSQL has not own data types, own operators library (language library), own dependency tracking. This is main difference from PL/SQL. PL/pgSQL is just very simple interpret that fully use types, functions, operators, dependency tracking implemented by Postgres for SQL support. Is not possible to implement variables with larger scope than transactions without Postgres dependency tracking.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2026-01-01T07:37:11Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, sql plus, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)
** Inside only PL (Oracle)
** Inside db engine (MySQL, T-SQL, DB2)

Another classification:
* external (are not part of SQL)
** server side (Oracle package variables)
** client side (psql, sql plus)
* native (are part of SQL)
** dedicated kind of database objects (DB2)
** declarative (T-SQL)
** implicit (MySQL)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PL/pgSQL has not own data types, own operators library (language library), own dependency tracking. This is main difference from PL/SQL. PL/pgSQL is just very simple interpret that fully use types, functions, operators, dependency tracking implemented by Postgres for SQL support. Is not possible to implement variables with larger scope than transactions without Postgres dependency tracking.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-11-25T05:21:16Z

Okbobcz: /* Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, sql plus, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)
** Inside only PL (Oracle)
** Inside db engine (MySQL, T-SQL, DB2)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PL/pgSQL has not own data types, own operators library (language library), own dependency tracking. This is main difference from PL/SQL. PL/pgSQL is just very simple interpret that fully use types, functions, operators, dependency tracking implemented by Postgres for SQL support. Is not possible to implement variables with larger scope than transactions without Postgres dependency tracking.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-06T05:51:13Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, sql plus, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)
** Inside only PL (Oracle)
** Inside db engine (MySQL, T-SQL, DB2)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-06T05:50:01Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)
** Inside only PL (Oracle)
** Inside db engine (MySQL, T-SQL, DB2)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-03T18:26:11Z

Okbobcz: /* Notes on Implementing Session Variables as Global Temporary Objects */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible uses of session variables include:

* Acting as global variables in PL code (for tracing, debugging, or quick hacks),
* Storing configuration values for PL routines,
* Keeping frequently used data handy in an interactive session,
* Storing credentials for Row-Level Security (RLS) and other data-protection mechanisms,
* Assisting with migrations from other systems (especially Oracle),
* Enabling parameterization of anonymous code blocks (specific to PostgreSQL).
* Session variables are writable even on read-only hot standby servers in PostgreSQL.

They behave somewhat like temporary tables, but there are important differences:

* Variables hold single values, while tables hold sets of rows.
* The syntax for using variables is shorter and more convenient for interactive work.
* Access (read/write) to variables is generally faster.
* The contents of session variables are typically non-transactional, whereas temporary tables are fully transactional.
* A session variable stores only a single value or NULL (no MVCC, no VACUUM).
* Temporary tables follow MVCC rules; repeated updates within a transaction generate many dead tuples, making updates more expensive.
* Temporary tables are not cleaned up by autovacuum, and it is not possible to run VACUUM inside a function.
* PostgreSQL does not support global temporary tables, so using a temporary table just to store a single value is inefficient and can lead to catalog bloat.

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design does not solve every problem --- for example, variables can still be shadowed by tables because of SEARCH_PATH (a known issue).

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL it would be possible to configure the parser to allow the use of session variables without a variable fence (similar to ordinary PL/pgSQL variables) in expressions. This is not supported yet, but implementation should not be problematic. Outside PL, variable fences could in principle be optional when there is no risk of collisions (for example, in expressions without subselects). This has not been implemented yet.

==== Assign Command LET ====

The value of a session variable can be assigned either by a dedicated LET command or by the SELECT INTO construct. In most systems where a special command is needed, the keyword SET is used (MySQL, MSSQL, SQL/PSM, DB2). In PostgreSQL, SET could be extended to support a_expr at the parser level, but this would require partially rewriting the current implementation of the SET command. Technically, this should not be a problem.

The main issue is the potential for collisions between GUCs and session variables. GUCs are not declared in advance, are not associated with a schema (the prefix for a custom GUC can be any non-empty string), and access is not controlled by SEARCH_PATH. A variable fence could also solve this issue, but in this case the risk is always present, so fences could not be optional. Some languages use the keyword LET for assignments. Introducing LET in PostgreSQL provides a clean way to eliminate collisions between GUCs and session variables.

It would also be possible to allow assignment to session variables in PL code using the usual PL assignment syntax (not yet implemented). This would be beneficial when porting from PL/SQL (Oracle) and would provide a natural syntax when using session variables as PL global variables. There do not appear to be technical obstacles to implementing this. However, one important issue arises: in PL/pgSQL, only declared variables can be targets of assignment statements. If session variables were allowed here, either (a) this check could not be performed, or (b) PL functions would gain a strong dependency on session variables, similar to the dependency on types today.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

While such dependencies may not be a problem (the plan cache can be invalidated correctly), they raise new questions about temporary variables. To avoid these complications, the LET command was introduced, meaning the PL/pgSQL assignment mechanism does not need to be modified.

A major consideration is performance, both in general and when LET is used inside PL/pgSQL.

The LET command is a PostgreSQL utility command. Like other utility commands (e.g., CREATE TABLE AS SELECT), it can be prepared. Patches exist to implement PREPARE and EXECUTE for LET (these are not included in the reduced patch set). Even though the plan cache can be used, LET may still perform worse than a PL/pgSQL assignment for two reasons:

* PL/pgSQL supports simple expression evaluation (also supported by LET in the enhanced patch set)
* PL/pgSQL variables are stored in arrays and accessed via an integer offset, while session variables are stored in a hash table and accessed via a hash lookup, which is slower. This slowdown is visible only in worst-case benchmarks:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

In the reduced patch set, the LET implementation is significantly slower because simple expression evaluation is not used (although it is implemented in the extended patch set). Nevertheless, even with the slowdown, execution remains much faster than queries that touch real tables, so performance should not be an issue in practice.

==== Notes on Implementing Session Variables as Global Temporary Objects ====

The core of this proposal is to design session variables as global temporary objects. Unfortunately, PostgreSQL currently has no support for this type of object. Surprisingly non-trivial is the implementation of non-system objects that have a catalogue entry, but unlike other objects, keep the data purely in memory. The problem is in memory cleaning. There is no hook that could be used to catch the event when the object was 100% deleted. We can (and must - there is nothing else) catch the sinval message, however, it is often delivered as a false alarm.

Two main issues arise with this design:

* the possibility of using invalid values (values stored in valid memory but no longer valid in the catalog),
* and memory cleanup happening too early or too late.

Each session variable is identified by name (and possibly by an OID from pg_variable). A variable may have its own data type. Values stored in memory are kept in native binary format and remain unchanged until reassigned. Important note: an OID can be reused over time --- OIDs are unique only at a single moment, and there is no guarantee that an OID will not later be assigned to a different object. This creates a real possibility of the following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

To prevent crashes, each stored value must be checked carefully before use. Checking only varid and typid is not sufficient. To ensure correctness, each variable can store its creation LSN (createlsn), which is unique throughout the lifetime of the database. Before using a value, the system checks that value.varid = catalog.varid and value.createlsn = catalog.createlsn. Type changes (ALTER VARIABLE ... ALTER TYPE) are not allowed. Dependencies ensure that the value type always matches the catalog type.

A second problem is deciding when to clean memory. Memory cannot be freed immediately after DROP VARIABLE because the command can be rolled back:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The simplest solution is to mark the variable as dropped and delay memory cleanup until the next transaction where variables are validated. This approach is simple and robust, although it means memory may only be freed after some delay. While this might look messy when monitoring memory usage, the catalog is transactional, and validation against the catalog ensures correctness.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-02T16:01:18Z

Okbobcz: /* Notes about implementation session variables as global temporary objects */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems. Outside PL, the variable fences can be optional, when there is not risk of collisions (the expression doesn't contains subselect) (not implemented yet).

==== Assign command - LET ====

The value of session variable can be assigned by dedicated PL assign command or by `SELECT INTO` construct. When special command is prefixed by some a keyword, then the keyword `SET` is usually used (MySQL, MSSQL, SQL/PSM, DB2). Command `SET` can be enhanced to support `a_expr` on parser level in Postgres too. It requires partial rewriting of current implementation of `SET` command, but there is not technical issues.

Unfortunately, there can be collisions between GUC and session variables. Currently GUC are not declared, and they are not joined to any schema (prefix for custom GUC can be just any not empty string), and access to GUC is not controlled by SEARCH_PATH. We can use same solution like usage session variables in expression - variable fence - but in this case, the risk is every time, and there is not a possibility to usage of variable fences can be optional (for some cases) in future. Some languages uses for a assignment the keyword `LET`. I introduced this keyword as a solution for 100% fix of collisions between GUC and session variables identifiers.

I can imagine the assignment to session variable inside PL by usual PL assignment command (not implemented yet). This can be benefit for translation from PL/SQL (Oracle), and it can be very natural syntax, when session variable is used like PL global variable. Probably (not tested), there are not technical issues for implementation of this. But there is different significant issue. Currently, only PL/pgSQL variables can be target of PL/pgSQL assign statement, and these variables should be declared before usage. If we allow session variables there, then a) we cannot to do this check, or b) there will be new strong dependency from PL functions to session variables - like on types now.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

The strong dependency today is not problem probably (because plan cache can be correctly invalidated), but there can be some new questions about temporary variables. Again as a solution I proposed a `LET` command, and we don't need to touch to PL/pgSQL assign statement.

The significant question is performance generally and performance when LET is used inside PL/pgSQL.

The command `LET` is PostgreSQL utility command. Against history, the utility command can be prepared (as `CREATE TABLE AS SELECT`). There are patches that implements `PREPARE` and `EXECUTE` for `LET` command (these patches are not in reduced patch set). Although plan cache can be used, the performance against PL/pgSQL assign can be slower - from two reasons:

* PL/pgSQL allows simple expression evaluation (this is supported for `LET` command too in enhanced patch set),
* PL/pgSQL variables are stored in a array (and indexed by int offset), session variables are stored in hash table, and they are accessed by hash search (and this slower). This slowdown is visible only in worst case benchmarks like:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

The implementation of `LET` in reduced patch set, is significantly slower, because the simple expression evaluation is not used (it is implemented, but not in reduced patch set). Although there is significant slowdown, the execution is still significantly faster than a execution of any query that touch to real table (it should not be a problem for real usage).

==== Notes about implementation session variables as global temporary objects ====
The core of this proposal is design of session variables as global temporary objects. Unfortunately, Postgres has zero support for this kind of objects. Session variables has not any session specific data in the catalog. This is much more better (and easier) than for global temporary tables. The data of session variables are in session memory (only). This is big difference from tables. There the data are stored in pages, and pages are stored in some files. The files are important - any cached data can be thrown (and they are frequently thrown). There are two kinds of new issues (related to session variables).

* possibility to use invalid value (stored in valid memory)
* too early or too delayed memory cleaning

Any session variable is identified by name (and possibly by oid from `pg_variable`). Any variable can use own data type. Values stored in memory are stored in native binary format, and without reassignment, the value is not changed. Important note - the one oid can be assigned more times. oids are unique in just one moment, but there is not a protection so one oid will not be used more times for different objects. There is a real possibility of following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

Before any usage of stored value, we need to do really identity check and varid and typid is not enough. But we can store to variable their create lsn - and this number is unique for all time database (catalog) live. So the necessary check before usage of stored value is just check if value.varid = catalog.varid and value.createlsn = catalog.createlsn. The ALTER VARIABLE ALTER TYPE is not allowed. The dependency mechanism ensure so value type should be identical with catalog type.

Second problem is when we can clean memory. We cannot to do immediately after command `DROP VARIABLE`, because this command can be reverted:

CREATE VARIABLE var AS int;
BEGIN;
LET var := 1;
DROP VARIABLE var;
ROLLBACK;
SELECT VARIABLE(var); -- expected 1

or

BEGIN;
CREATE VARIABLE var AS int;
LET var := 1;
ROLLBACK;
-- var should be removed from memory

or

BEGIN;
CREATE VARIABLE var AS int;
SAVEPOINT s1;
LET var := 1;
DROP VARIABLE var;
ROLLBACK TO s1;
COMMIT;
SELECT VARIABLE(var); -- expected 1

The most simple solution is marking variable as dropped, and in next transaction when we validate variables (values), we can clean memory after dropped variables. This technique is very simple, and robust, on second hand, the memory is cleaned after any operation with session variable, what can be after long time or maybe messy (if somebody will check used memory). Fortunately, catalogue is transactional, and then we can validate data against catalogue entry.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-02T11:26:43Z

Okbobcz: /* Notes about implementation session variables as global temporary objects */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems. Outside PL, the variable fences can be optional, when there is not risk of collisions (the expression doesn't contains subselect) (not implemented yet).

==== Assign command - LET ====

The value of session variable can be assigned by dedicated PL assign command or by `SELECT INTO` construct. When special command is prefixed by some a keyword, then the keyword `SET` is usually used (MySQL, MSSQL, SQL/PSM, DB2). Command `SET` can be enhanced to support `a_expr` on parser level in Postgres too. It requires partial rewriting of current implementation of `SET` command, but there is not technical issues.

Unfortunately, there can be collisions between GUC and session variables. Currently GUC are not declared, and they are not joined to any schema (prefix for custom GUC can be just any not empty string), and access to GUC is not controlled by SEARCH_PATH. We can use same solution like usage session variables in expression - variable fence - but in this case, the risk is every time, and there is not a possibility to usage of variable fences can be optional (for some cases) in future. Some languages uses for a assignment the keyword `LET`. I introduced this keyword as a solution for 100% fix of collisions between GUC and session variables identifiers.

I can imagine the assignment to session variable inside PL by usual PL assignment command (not implemented yet). This can be benefit for translation from PL/SQL (Oracle), and it can be very natural syntax, when session variable is used like PL global variable. Probably (not tested), there are not technical issues for implementation of this. But there is different significant issue. Currently, only PL/pgSQL variables can be target of PL/pgSQL assign statement, and these variables should be declared before usage. If we allow session variables there, then a) we cannot to do this check, or b) there will be new strong dependency from PL functions to session variables - like on types now.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

The strong dependency today is not problem probably (because plan cache can be correctly invalidated), but there can be some new questions about temporary variables. Again as a solution I proposed a `LET` command, and we don't need to touch to PL/pgSQL assign statement.

The significant question is performance generally and performance when LET is used inside PL/pgSQL.

The command `LET` is PostgreSQL utility command. Against history, the utility command can be prepared (as `CREATE TABLE AS SELECT`). There are patches that implements `PREPARE` and `EXECUTE` for `LET` command (these patches are not in reduced patch set). Although plan cache can be used, the performance against PL/pgSQL assign can be slower - from two reasons:

* PL/pgSQL allows simple expression evaluation (this is supported for `LET` command too in enhanced patch set),
* PL/pgSQL variables are stored in a array (and indexed by int offset), session variables are stored in hash table, and they are accessed by hash search (and this slower). This slowdown is visible only in worst case benchmarks like:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

The implementation of `LET` in reduced patch set, is significantly slower, because the simple expression evaluation is not used (it is implemented, but not in reduced patch set). Although there is significant slowdown, the execution is still significantly faster than a execution of any query that touch to real table (it should not be a problem for real usage).

==== Notes about implementation session variables as global temporary objects ====
The core of this proposal is design of session variables as global temporary objects. Unfortunately, Postgres has zero support for this kind of objects. Session variables has not any session specific data in the catalog. This is much more better (and easier) than for global temporary tables. The data of session variables are in session memory (only). This is big difference from tables. There the data are stored in pages, and pages are stored in some files. The files are important - any cached data can be thrown (and they are frequently thrown). There are two kinds of new issues (related to session variables).

* possibility to use invalid value (stored in valid memory)
* too early or too delayed memory cleaning

Any session variable is identified by name (and possibly by oid from `pg_variable`). Any variable can use own data type. Values stored in memory are stored in native binary format, and without reassignment, the value is not changed. Important note - the one oid can be assigned more times. oids are unique in just one moment, but there is not a protection so one oid will not be used more times for different objects. There is a real possibility of following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

Before any usage of stored value, we need to do really identity check and varid and typid is not enough. But we can store to variable their create lsn - and this number is unique for all time database (catalog) live. So the necessary check before usage of stored value is just check if value.varid = catalog.varid and value.createlsn = catalog.createlsn. The ALTER VARIABLE ALTER TYPE is not allowed. The dependency mechanism ensure so value type should be identical with catalog type.

Second problem is when we can clean memory. We cannot to do immediately after command `DROP VARIABLE`, because this command can be reverted

CREATE VARIABLE var AS int;
BEGIN;

LET var := 1;
DROP VARIABLE var;

ROLLBACK;

The most simple solution is marking variable as dropped, and in next transaction when we validate variables (values), we can clean memory after dropped variables. This technique is very simple, and robust, on second hand, the memory is cleaned after any operation with session variable, what can be after long time or maybe messy (if somebody will check used memory). We can do this check in transaction end or transaction begin - but it can be small overhead any time, although session variables was not used.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-02T11:19:12Z

Okbobcz: /* Notes about implementation session variables as global temporary objects */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems. Outside PL, the variable fences can be optional, when there is not risk of collisions (the expression doesn't contains subselect) (not implemented yet).

==== Assign command - LET ====

The value of session variable can be assigned by dedicated PL assign command or by `SELECT INTO` construct. When special command is prefixed by some a keyword, then the keyword `SET` is usually used (MySQL, MSSQL, SQL/PSM, DB2). Command `SET` can be enhanced to support `a_expr` on parser level in Postgres too. It requires partial rewriting of current implementation of `SET` command, but there is not technical issues.

Unfortunately, there can be collisions between GUC and session variables. Currently GUC are not declared, and they are not joined to any schema (prefix for custom GUC can be just any not empty string), and access to GUC is not controlled by SEARCH_PATH. We can use same solution like usage session variables in expression - variable fence - but in this case, the risk is every time, and there is not a possibility to usage of variable fences can be optional (for some cases) in future. Some languages uses for a assignment the keyword `LET`. I introduced this keyword as a solution for 100% fix of collisions between GUC and session variables identifiers.

I can imagine the assignment to session variable inside PL by usual PL assignment command (not implemented yet). This can be benefit for translation from PL/SQL (Oracle), and it can be very natural syntax, when session variable is used like PL global variable. Probably (not tested), there are not technical issues for implementation of this. But there is different significant issue. Currently, only PL/pgSQL variables can be target of PL/pgSQL assign statement, and these variables should be declared before usage. If we allow session variables there, then a) we cannot to do this check, or b) there will be new strong dependency from PL functions to session variables - like on types now.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

The strong dependency today is not problem probably (because plan cache can be correctly invalidated), but there can be some new questions about temporary variables. Again as a solution I proposed a `LET` command, and we don't need to touch to PL/pgSQL assign statement.

The significant question is performance generally and performance when LET is used inside PL/pgSQL.

The command `LET` is PostgreSQL utility command. Against history, the utility command can be prepared (as `CREATE TABLE AS SELECT`). There are patches that implements `PREPARE` and `EXECUTE` for `LET` command (these patches are not in reduced patch set). Although plan cache can be used, the performance against PL/pgSQL assign can be slower - from two reasons:

* PL/pgSQL allows simple expression evaluation (this is supported for `LET` command too in enhanced patch set),
* PL/pgSQL variables are stored in a array (and indexed by int offset), session variables are stored in hash table, and they are accessed by hash search (and this slower). This slowdown is visible only in worst case benchmarks like:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

The implementation of `LET` in reduced patch set, is significantly slower, because the simple expression evaluation is not used (it is implemented, but not in reduced patch set). Although there is significant slowdown, the execution is still significantly faster than a execution of any query that touch to real table (it should not be a problem for real usage).

==== Notes about implementation session variables as global temporary objects ====
The core of this proposal is design of session variables as global temporary objects. Unfortunately, Postgres has zero support for this kind of objects. Session variables has not any session specific data in the catalog. This is much more better (and easier) than for global temporary tables. The data of session variables are in session memory (only). This is big difference from tables. There the data are stored in pages, and pages are stored in some files. The files are important - any cached data can be thrown (and they are frequently thrown). There are two kinds of new issues (related to session variables).

* possibility to use invalid value (stored in valid memory)
* too early or too delayed memory cleaning

Any session variable is identified by name (and possibly by oid from `pg_variable`). Any variable can use own data type. Values stored in memory are stored in native binary format, and without reassignment, the value is not changed. Important note - the one oid can be assigned more times. oids are unique in just one moment, but there is not a protection so one oid will not be used more times for different objects. There is a real possibility of following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

Before any usage of stored value, we need to do really identity check and varid and typid is not enough. But we can store to variable their create lsn - and this number is unique for all time database (catalog) live. So the necessary check before usage of stored value is just check if value.varid = catalog.varid and value.createlsn = catalog.createlsn. The ALTER VARIABLE ALTER TYPE is not allowed. The dependency mechanism ensure so value type should be identical with catalog type.

Second problem is when we can clean memory. We cannot to do immediately after command `DROP VARIABLE`, because this command can be reverted

CREATE VARIABLE var AS int;
BEGIN;

LET var := 1;
DROP VARIABLE var;

ROLLBACK;

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-02T07:04:37Z

Okbobcz: /* Notes about implementation session variables as global temporary objects */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems. Outside PL, the variable fences can be optional, when there is not risk of collisions (the expression doesn't contains subselect) (not implemented yet).

==== Assign command - LET ====

The value of session variable can be assigned by dedicated PL assign command or by `SELECT INTO` construct. When special command is prefixed by some a keyword, then the keyword `SET` is usually used (MySQL, MSSQL, SQL/PSM, DB2). Command `SET` can be enhanced to support `a_expr` on parser level in Postgres too. It requires partial rewriting of current implementation of `SET` command, but there is not technical issues.

Unfortunately, there can be collisions between GUC and session variables. Currently GUC are not declared, and they are not joined to any schema (prefix for custom GUC can be just any not empty string), and access to GUC is not controlled by SEARCH_PATH. We can use same solution like usage session variables in expression - variable fence - but in this case, the risk is every time, and there is not a possibility to usage of variable fences can be optional (for some cases) in future. Some languages uses for a assignment the keyword `LET`. I introduced this keyword as a solution for 100% fix of collisions between GUC and session variables identifiers.

I can imagine the assignment to session variable inside PL by usual PL assignment command (not implemented yet). This can be benefit for translation from PL/SQL (Oracle), and it can be very natural syntax, when session variable is used like PL global variable. Probably (not tested), there are not technical issues for implementation of this. But there is different significant issue. Currently, only PL/pgSQL variables can be target of PL/pgSQL assign statement, and these variables should be declared before usage. If we allow session variables there, then a) we cannot to do this check, or b) there will be new strong dependency from PL functions to session variables - like on types now.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

The strong dependency today is not problem probably (because plan cache can be correctly invalidated), but there can be some new questions about temporary variables. Again as a solution I proposed a `LET` command, and we don't need to touch to PL/pgSQL assign statement.

The significant question is performance generally and performance when LET is used inside PL/pgSQL.

The command `LET` is PostgreSQL utility command. Against history, the utility command can be prepared (as `CREATE TABLE AS SELECT`). There are patches that implements `PREPARE` and `EXECUTE` for `LET` command (these patches are not in reduced patch set). Although plan cache can be used, the performance against PL/pgSQL assign can be slower - from two reasons:

* PL/pgSQL allows simple expression evaluation (this is supported for `LET` command too in enhanced patch set),
* PL/pgSQL variables are stored in a array (and indexed by int offset), session variables are stored in hash table, and they are accessed by hash search (and this slower). This slowdown is visible only in worst case benchmarks like:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

The implementation of `LET` in reduced patch set, is significantly slower, because the simple expression evaluation is not used (it is implemented, but not in reduced patch set). Although there is significant slowdown, the execution is still significantly faster than a execution of any query that touch to real table (it should not be a problem for real usage).

==== Notes about implementation session variables as global temporary objects ====
The core of this proposal is design of session variables as global temporary objects. Unfortunately, Postgres has zero support for this kind of objects. Session variables has not any session specific data in the catalog. This is much more better (and easier) than for global temporary tables. The data of session variables are in session memory (only). This is big difference from tables. There the data are stored in pages, and pages are stored in some files. The files are important - any cached data can be thrown (and they are frequently thrown). There are two kinds of new issues (related to session variables).

* possibility to use invalid value (stored in valid memory)
* too early or too delayed memory cleaning

Any session variable is identified by name (and possibly by oid from `pg_variable`). Any variable can use own data type. Values stored in memory are stored in native binary format, and without reassignment, the value is not changed. Important note - the one oid can be assigned more times. oids are unique in just one moment, but there is not a protection so one oid will not be used more times for different objects. There is a real possibility of following issue:

* session A: CREATE VARIABLE v AS t;
* session B: LET v = t 'value';
* session A: DROP VARIABLE v;
* session B: no activity -- it got lot of sinval messages (signals), but no command is executed, and then is not possibility to handle sinval
* session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
* session B: SELECT v; -- crash

Before any usage of stored value, we need to do really identity check and varid and typid is not enough. But we can store to variable their create lsn - and this number is unique for all time database (catalog) live. So the necessary check before usage of stored value is just check if value.varid = catalog.varid and value.createlsn = catalog.createlsn. The ALTER VARIABLE ALTER TYPE is not allowed. The dependency mechanism ensure so value type should be identical with catalog type.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-02T07:02:15Z

Okbobcz: /* Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems. Outside PL, the variable fences can be optional, when there is not risk of collisions (the expression doesn't contains subselect) (not implemented yet).

==== Assign command - LET ====

The value of session variable can be assigned by dedicated PL assign command or by `SELECT INTO` construct. When special command is prefixed by some a keyword, then the keyword `SET` is usually used (MySQL, MSSQL, SQL/PSM, DB2). Command `SET` can be enhanced to support `a_expr` on parser level in Postgres too. It requires partial rewriting of current implementation of `SET` command, but there is not technical issues.

Unfortunately, there can be collisions between GUC and session variables. Currently GUC are not declared, and they are not joined to any schema (prefix for custom GUC can be just any not empty string), and access to GUC is not controlled by SEARCH_PATH. We can use same solution like usage session variables in expression - variable fence - but in this case, the risk is every time, and there is not a possibility to usage of variable fences can be optional (for some cases) in future. Some languages uses for a assignment the keyword `LET`. I introduced this keyword as a solution for 100% fix of collisions between GUC and session variables identifiers.

I can imagine the assignment to session variable inside PL by usual PL assignment command (not implemented yet). This can be benefit for translation from PL/SQL (Oracle), and it can be very natural syntax, when session variable is used like PL global variable. Probably (not tested), there are not technical issues for implementation of this. But there is different significant issue. Currently, only PL/pgSQL variables can be target of PL/pgSQL assign statement, and these variables should be declared before usage. If we allow session variables there, then a) we cannot to do this check, or b) there will be new strong dependency from PL functions to session variables - like on types now.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

The strong dependency today is not problem probably (because plan cache can be correctly invalidated), but there can be some new questions about temporary variables. Again as a solution I proposed a `LET` command, and we don't need to touch to PL/pgSQL assign statement.

The significant question is performance generally and performance when LET is used inside PL/pgSQL.

The command `LET` is PostgreSQL utility command. Against history, the utility command can be prepared (as `CREATE TABLE AS SELECT`). There are patches that implements `PREPARE` and `EXECUTE` for `LET` command (these patches are not in reduced patch set). Although plan cache can be used, the performance against PL/pgSQL assign can be slower - from two reasons:

* PL/pgSQL allows simple expression evaluation (this is supported for `LET` command too in enhanced patch set),
* PL/pgSQL variables are stored in a array (and indexed by int offset), session variables are stored in hash table, and they are accessed by hash search (and this slower). This slowdown is visible only in worst case benchmarks like:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

The implementation of `LET` in reduced patch set, is significantly slower, because the simple expression evaluation is not used (it is implemented, but not in reduced patch set). Although there is significant slowdown, the execution is still significantly faster than a execution of any query that touch to real table (it should not be a problem for real usage).

==== Notes about implementation session variables as global temporary objects ====
The core of this proposal is design of session variables as global temporary objects. Unfortunately, Postgres has zero support for this kind of objects. Session variables has not any session specific data in the catalog. This is much more better (and easier) than for global temporary tables. The data of session variables are in session memory (only). This is big difference from tables. There the data are stored in pages, and pages are stored in some files. The files are important - any cached data can be thrown (and they are frequently thrown). There are two kinds of new issues (related to session variables).

* possibility to use invalid value (stored in valid memory)
* too early or too delayed memory cleaning

Any session variable is identified by name (and possibly by oid from `pg_variable`). Any variable can use own data type. Values stored in memory are stored in native binary format, and without reassignment, the value is not changed. Important note - the one oid can be assigned more times. oids are unique in just one moment, but there is not a protection so one oid will not be used more times for different objects. There is a real possibility of following issue:

1. session A: CREATE VARIABLE v AS t;
2. session B: LET v = t 'value';
3. session A: DROP VARIABLE v;
4. session B: no activity
5. session A: CREATE VARIABLE v AS nt; -- theoretically I can get same varid and typid like in first step, although t != nt
6. session B: SELECT v; -- crash

Before any usage of stored value, we need to do really identity check and varid and typid is not enough. But we can store to variable their create lsn - and this number is unique for all time database (catalog) live. So the necessary check before usage of stored value is just check if value.varid = catalog.varid and value.createlsn = catalog.createlsn. The ALTER VARIABLE ALTER TYPE is not allowed. The dependency mechanism ensure so value type should be identical with catalog type.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-02T06:21:14Z

Okbobcz: /* Assign command - LET */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems. Outside PL, the variable fences can be optional, when there is not risk of collisions (the expression doesn't contains subselect) (not implemented yet).

==== Assign command - LET ====

The value of session variable can be assigned by dedicated PL assign command or by `SELECT INTO` construct. When special command is prefixed by some a keyword, then the keyword `SET` is usually used (MySQL, MSSQL, SQL/PSM, DB2). Command `SET` can be enhanced to support `a_expr` on parser level in Postgres too. It requires partial rewriting of current implementation of `SET` command, but there is not technical issues.

Unfortunately, there can be collisions between GUC and session variables. Currently GUC are not declared, and they are not joined to any schema (prefix for custom GUC can be just any not empty string), and access to GUC is not controlled by SEARCH_PATH. We can use same solution like usage session variables in expression - variable fence - but in this case, the risk is every time, and there is not a possibility to usage of variable fences can be optional (for some cases) in future. Some languages uses for a assignment the keyword `LET`. I introduced this keyword as a solution for 100% fix of collisions between GUC and session variables identifiers.

I can imagine the assignment to session variable inside PL by usual PL assignment command (not implemented yet). This can be benefit for translation from PL/SQL (Oracle), and it can be very natural syntax, when session variable is used like PL global variable. Probably (not tested), there are not technical issues for implementation of this. But there is different significant issue. Currently, only PL/pgSQL variables can be target of PL/pgSQL assign statement, and these variables should be declared before usage. If we allow session variables there, then a) we cannot to do this check, or b) there will be new strong dependency from PL functions to session variables - like on types now.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

The strong dependency today is not problem probably (because plan cache can be correctly invalidated), but there can be some new questions about temporary variables. Again as a solution I proposed a `LET` command, and we don't need to touch to PL/pgSQL assign statement.

The significant question is performance generally and performance when LET is used inside PL/pgSQL.

The command `LET` is PostgreSQL utility command. Against history, the utility command can be prepared (as `CREATE TABLE AS SELECT`). There are patches that implements `PREPARE` and `EXECUTE` for `LET` command (these patches are not in reduced patch set). Although plan cache can be used, the performance against PL/pgSQL assign can be slower - from two reasons:

* PL/pgSQL allows simple expression evaluation (this is supported for `LET` command too in enhanced patch set),
* PL/pgSQL variables are stored in a array (and indexed by int offset), session variables are stored in hash table, and they are accessed by hash search (and this slower). This slowdown is visible only in worst case benchmarks like:

DO $$ declare locvar int DEFAULT 0; begin for i in 1..1000000 loop locvar := locvar + 1; end loop; end $$
DO $$ begin for i in 1..100000 loop LET sesvar := sesvar + 1; end loop; end $$

The implementation of `LET` in reduced patch set, is significantly slower, because the simple expression evaluation is not used (it is implemented, but not in reduced patch set). Although there is significant slowdown, the execution is still significantly faster than a execution of any query that touch to real table (it should not be a problem for real usage).

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-10-02T05:56:31Z

Okbobcz: /* Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems. Outside PL, the variable fences can be optional, when there is not risk of collisions (the expression doesn't contains subselect) (not implemented yet).

==== Assign command - LET ====

The value of session variable can be assigned by dedicated PL assign command or by `SELECT INTO` construct. When special command is prefixed by some a keyword, then the keyword `SET` is usually used (MySQL, MSSQL, SQL/PSM, DB2). Command `SET` can be enhanced to support `a_expr` on parser level in Postgres too. It requires partial rewriting of current implementation of `SET` command, but there is not technical issues.

Unfortunately, there can be collisions between GUC and session variables. Currently GUC are not declared, and they are not joined to any schema (prefix for custom GUC can be just any not empty string), and access to GUC is not controlled by SEARCH_PATH. We can use same solution like usage session variables in expression - variable fence - but in this case, the risk is every time, and there is not a possibility to usage of variable fences can be optional (for some cases) in future. Some languages uses for a assignment the keyword `LET`. I introduced this keyword as a solution for 100% fix of collisions between GUC and session variables identifiers.

I can imagine the assignment to session variable inside PL by usual PL assignment command (not implemented yet). This can be benefit for translation from PL/SQL (Oracle), and it can be very natural syntax, when session variable is used like PL global variable. Probably (not tested), there are not technical issues for implementation of this. But there is different significant issue. Currently, only PL/pgSQL variables can be target of PL/pgSQL assign statement, and these variables should be declared before usage. If we allow session variables there, then a) we cannot to do this check, or b) there will be new strong dependency from PL functions to session variables - like on types now.

(2025-10-02 07:42:01) postgres=# CREATE OR REPLACE FUNCTION fx()
returns void as $$
begin
declare var mydomain;
begin
var := 10;
end
$$ language plpgsql;
ERROR: type "mydomain" does not exist
LINE 4: declare var mydomain;
^

The strong dependency today is not problem probably (because plan cache can be correctly invalidated), but there can be some new questions about temporary variables. Again as a solution I proposed a `LET` command, and we don't need to touch to PL/pgSQL assign statement.

The significant question is performance generally and performance when LET is used inside PL/pgSQL.

The command `LET` is PostgreSQL utility command. Against history, the utility command can be prepared (as `CREATE TABLE AS SELECT`). There are patches that implements `PREPARE` and `EXECUTE` for `LET` command (these patches are not in reduced patch set). Although plan cache can be used, the performance against PL/pgSQL assign can be slower - from two reasons:

* PL/pgSQL allows simple expression evaluation (this is supported for `LET` command too in enhanced patch set),
* PL/pgSQL variables are stored in a array (and indexed by int offset), session variables are stored in hash table, and they are accessed by hash search (and this slower).

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-30T05:42:57Z

Okbobcz: /* Collisions between column and variable identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

Inside PL/pgSQL we can use a possibility to configure a parser, and can be easy to allow a usage of session variables without variable fence (like common plpgsql variable) in expressions. It is not supported yet, but there should not be implementation problems.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-30T05:29:43Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* temporary tables are tables still (transactional, MVCC), update is expensive, under one transaction repeated updates makes lot of dead tuples,
* temporary tables are not cleaned by autovacuum (and inside function is not possible to execute VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-30T04:19:49Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

Session variables holds a values like temporary tables. What are differences between temporary tables and variables?:

* variables holds a values, tables holds a set of rows,
* syntax for usage variables is shorter (more friendly for interactive work), access (read, write) is faster,
* the content of session variables is generally non transactional, the content of temporary tables is transactional,
* the content of session variables is just one value or NULL (no MVCC, no VACUUM),
* Postgres doesn't support global temporary tables, so usage of temporary table for just few values or value is very expensive (catalogue bloat).

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-30T04:08:30Z

Okbobcz: /* Collisions between column and variable identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables). This design doesn't solve all possible problems - variables can be shadowed by tables still, because we have SEARCH_PATH (but this is known issue):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-30T04:05:44Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).
* session variables are writeable on read only hot standby (postgres)

= SQL/PSM =

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

= Implementation Challenges =

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

= Proposed Implementations =

It is clear that no single design is perfect for all use cases. MySQL’s approach is convenient and useful for interactive work, but it cannot be used for storing sensitive data and is considered unsafe. PostgreSQL GUCs are excellent for configuration, but they are not well suited for interactive use and are very limited when used as global variables in PL code.

Because of these trade-offs, no single design is sufficient. In practice, having multiple designs within a single system could support a broader range of use cases more effectively.

== Design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

Author: Pavel Stehule <pavel.stehule@gmail.com>

I searched for a solution that could work well with the specific PostgreSQL environment:

* PostgreSQL has more than one widely used stored procedure language: PL/pgSQL, PL/Python, or PL/Perl.

* PL/pgSQL is a reduced version of PL/SQL, and PL/SQL is a modified ADA language. I am pretty happy with the current complexity of PL/pgSQL --- it is a domain-specific language that works well. It is very simple and easy to learn. PL/pgSQL has no packages or modules; instead PostgreSQL schemas are used. But schemas are database objects in their own right, independent of PL.

* PostgreSQL already has a code container --- the schema. I don't want to introduce another container object (modules), as this would overlap heavily with schemas. Implementing modules for PL/pgSQL could be useful, but doing it properly would be quite complex. The main problem is the concept of public and private objects --- PostgreSQL does not have this. Don't forget: every PL/pgSQL expression is a SQL expression, so public/private visibility would first need to be implemented internally in PostgreSQL. That would be redundant (and possibly in conflict) with SEARCH_PATH.

So I wanted a design that supports multiple PL languages, does not add complexity to the relatively simple PL/pgSQL, and does not duplicate functionality already available.

I wrote a larger application in PL/pgSQL. To maintain it, I created plpgsql_lint (later renamed plpgsql_check). So I am always looking for solutions that do not block static code analysis. Static analysis requires persistent objects, which naturally leads to designing session variables as database objects (with their own system catalog).
When session variables are database objects, ACLs can be applied naturally. Oracle package variables are well protected by package scope. PostgreSQL, however, has no schema scope --- schema locality is controlled by the SEARCH_PATH GUC, and introducing another mechanism would be messy. But with ACLs, variable contents can also be secured:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between column and variable identifiers ====

There is a risk of identifier collisions between variables and columns. With ANSI SQL syntax for session variable identifiers, the problem is how to distinguish variables from columns. This is a known issue in PL/pgSQL and PL/SQL and can be solved either by prioritization or by prohibiting collisions.

Prohibiting collisions has largely solved this problem in PL/pgSQL. Unfortunately, session variables are global objects, so collisions can occur in any query. A poorly named variable could break queries unexpectedly. Prioritization also has problems --- a variable or a column could be used silently when the other was intended.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, this query fails when a variable named "a" exists

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables, all rows could be deleted
SELECT a FROM tab; -- with higher priority for columns, the variable is ignored

Even with collision prohibition, mistakes are still possible:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just a typo, but all rows are deleted

These problems are not new. Developers in PL/pgSQL or PL/SQL know them, but the scope of risk is normally limited to stored procedures. After many discussions and designs, I introduced "variable fences" (the syntax VARIABLE(varname)). Inside any query, variables can be used only inside a variable fence. This completely solves collisions and reduces the chance of human error. Currently, fences are required everywhere in queries and expressions. In the future, they might be made optional inside PL/pgSQL, to reduce overhead when porting Oracle applications. This could be controlled by a new plpgsql.extra_checks setting.

A variable fence can collide with a user-defined function named `variable`. This is similar to keyword conflicts such as CUBE. It can be resolved by schema-qualifying or quoting:

SELECT public.variable(...)
SELECT "variable"(...)

Why not use T-SQL (MSSQL, MySQL) syntax for session variables? There are several reasons – some objective, one subjective:

* There is a collision with custom operators. Operators `@` and `@@` are already used, and `@@` is common:

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We could safely use only `:` as a prefix, but that would conflict with psql variables. Similarly, `$` would conflict with query parameters.

* T-SQL variable names look strange in PostgreSQL (in queries and in PL/pgSQL). PostgreSQL uses only ANSI/SQL identifiers, and PL/pgSQL follows the same rules. PostgreSQL is consistent here, and I see little motivation to introduce a new, non-standard syntax (especially since it could cause compatibility issues).

Note: There was also a proposal to use table syntax for variables (similar to T-SQL in-memory table variables, but restricted to a single row). This is very effective for avoiding collisions, but I dislike it. It complicates simple expressions, adds inconsistency, and looks odd for scalar variables (though it could be useful for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable as a table (I don't like it)
-- can we use DML? How many rows can it hold?
-- is the value a row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against introducing in-memory tables --- or more correctly, global temporary tables. A well-designed implementation could be very useful. But this is a different feature and should be designed separately.

There are also performance considerations: PL/pgSQL can use simple expression evaluation when no tables are referenced. This optimization would need to change, which touches sensitive code. It would also be inconsistent.

I would like global temporary tables (which PostgreSQL currently lacks). Tables should behave like tables, and variables should behave like variables. The natural mental model for session variables comes from variables in PL languages. PostgreSQL internally supports *transition tables*, and I can imagine allowing these outside of triggers. That would be valid, but again, it is a different feature.

Implementing declared tables inside PL/pgSQL would be simpler from a high-level design perspective (interaction between SQL tables and PL/pgSQL is already well defined), but difficult from a low-level perspective (statistics, optimizer data, etc. --- the same issues as with global temporary tables, unless we add fake proxy local temp tables).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages define relational variables, but this concept has no overlap with the common understanding of session variables.

= Variabes in PostgreSQL (as of v18) =

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

= Session Variables in Other Systems =

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

== MySQL ==

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

== Oracle ==

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

== MSSQL (T-SQL) ==

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

= ToDo =

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T07:06:14Z

Okbobcz: /* Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

== Proposed Implementations ==

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current comlexity of PL/pgSQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

* Postgres has already code container - schema. I don't want to introduce additional new container object - modules, with strong overlap with schemas. Implementation of modules for PL/pgSQL can be useful, but can be pretty complex if it should be done well. The main problem is in concept public, private objects - PostgreSQL doesn't know it. Don't forget - any PL/pgSQL expression is SQL expression, so public, private objects should be implemented internally in Postgres first - and this mechanism is redundant (and in collision) to SEARCH_PATH.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between columns and variables identifiers ====
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just typo (unwanted _), but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T07:00:08Z

Okbobcz: /* Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

== Proposed Implementations ==

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current comlexity of PL/pgSQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

* Postgres has already code container - schema. I don't want to introduce additional new container object - modules, with strong overlap with schemas.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between columns and variables identifiers ====
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just typo (unwanted _), but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T04:45:28Z

Okbobcz: /* Collisions between columns and variables identifiers */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

== Proposed Implementations ==

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between columns and variables identifiers ====
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just typo (unwanted _), but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T04:37:41Z

Okbobcz: /* Oracle */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

== Proposed Implementations ==

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between columns and variables identifiers ====
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T04:32:39Z

Okbobcz: /* MSSQL (T-SQL) */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

== Proposed Implementations ==

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between columns and variables identifiers ====
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T04:30:53Z

Okbobcz: /* Introduction */

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with priprietary syntax for identifiers (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

== Proposed Implementations ==

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between columns and variables identifiers ====
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables** — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T04:30:04Z

Okbobcz: reaply Jim's editorial work and some reorganization

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

Kinds of session variables:
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

Possible usage of session variables:

* usage of session variables as global variables in PL (tracing, debugging, hacking),
* holding configuration (for PL),
* holding some more used data in interactive session,
* holding credentials for some RLS and data securing,
* helping with migration from others systems (mainly from Oracle),
* allow anonymous block parametrization (only postgres).

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas (partially). Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules can encapsulate private objects (functions, procedure, temp tables), that are not visible outside the module. Inside the module, a private objects shadows other objects. What I know the modules (and generally SQL/PSM) doesn't cover a deployment of code, so there is not similarity with PostgreSQL extensions. SQL/PSM Modules are modules like modules from modular languages like Modula2 or Oberon. There is some similarity with Postgres schemas (both are containers) with significant differences (there is not a concept of SEARCH_PATH (on PSM side) or there is not a concept of private or public objects (on Postgres schema side)).

SQL/PSM variables are not transactional (they are used exactly like in PL/pgSQL). The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted (Postgres has not support for global temp objects).
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it (Postgres has not support for global temp objects).

== Proposed Implementations ==

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

==== Collisions between columns and variables identifiers ====
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
Thu Sep 25 09:43:55 CEST 2025

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behaviour, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

* system variables - referenced using the `@@` prefix (or `@@scope.name`)
* user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables** — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

Implementation of declarative catalog session variables

2025-09-29T03:56:03Z

Okbobcz: Undo revision 41829 by Jimus (talk)

= Introduction =

Session variables are database objects that can hold a value across multiple queries inside a session. The design of session variables varies widely, and many databases implement more than one type of session variable.

The SQL/PSM standard introduces modules and module-level variables. However, this part of the standard has not been implemented in any widely used product. As a result, each database system has developed its own proprietary design, syntax, and feature set.

Session variables are often part of the stored procedure environment, but there are exceptions --- for example, MySQL session variables or client-side session variables in tools like psql. In most systems, session variables do not participate in transactions: once set, their value persists until explicitly changed, even if the surrounding transaction is rolled back. Conceptually, they behave much like variables in general-purpose programming languages.

Because there is no common design, comparisons across systems are difficult. Each implementation has its own advantages and disadvantages, and in some cases a single system supports more than one kind of session variable.

== SQL/PSM ==

The SQL standard introduces the concept of modules, which can be associated with schemas. Variables in modules behave like PL/pgSQL variables but are only local. The only objects allowed at the module level are temporary tables, which can be accessed only from routines assigned to that module. Modules are essentially declarative versions of extensions (if I understand correctly; I did not find an implementation). They allow you to override the search path for routines assigned to the module. Variables are not transactional. The precedence between variables and columns is not specified.

== Implementation Challenges ==

* Possible collisions between session variables and other database objects.
* Memory cleanup after dropping a session variable, especially when DDL operations can be reverted.
* Memory invalidation: if a variable is dropped by one session, other sessions should not continue using it.

== Proposed Implementations ==

=== Catalog Schema Variables ===

== Variabes in PostgreSQL (as of v18) ==

PostgreSQL provides relatively advanced client-side session variables in psql --- these variables use the `:` prefix. The implementation is pretty much straightforward: `psql`'s parser reads tokens from input and, when it encounters a token related to a variable, replaces it with the variable's value. The syntax supports literal and identifier escaping, and variables can be used as arguments of the `\bind` command.

`psql` variables are typeless client-side variables, available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

The `\set` command allows only simple string concatenation, but it also supports execution of shell commands. When a query is executed with the `\gset` command, its result can be stored in a `psql` variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

The `\set` command is fairly limited, making complex operations unreadable or non-portable.

This mechanism is good enough for writing tests, but it is not generally available (most users do not need it), and it is not accessible from the server side (e.g., from stored procedures). There is no simple way to access `psql` variables from an anonymous block --- a proxy custom GUC variable must be used:

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar',
:'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL also has configuration variables (GUC - Grand Unified Configuration). These are primarily designed for PostgreSQL and
extension configuration, but they can be used as session variables. GUC variables can be set with the `SET` command or the `set_config` function, and read with `SHOW` or `current_setting`.

GUC variables are meant for holding configuration parameters. When created through the internal API, they can be restricted to superusers, hidden from regular users, and assigned specific types (boolean, memory, number, interval, string, enum) with validation. This type system is separate from the SQL type system and is initialized before PostgreSQL’s SQL types.

Variables created from SQL must be "custom" variables, using a prefix in their name --- these are always strings. Such custom GUCs are often used as a workaround for missing server-side session variables in PostgreSQL, but they are typeless, unprotected, and unsafe.

A notable feature of PostgreSQL GUCs (built-in or custom) is that they can have different scopes: transaction, session, or function execution. They can also be assigned default values at specific events --- configuration loading, role login, database login, or function start. These features are useful for configuration, but problematic when GUCs are repurposed as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional, and this behavior cannot be disabled.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

As a result, there is no reliable way to store details such as error information in custom GUCs.

== Session Variables in Other Systems ==

This section surveys how session variables are implemented in several widely used database systems. Each subsection includes code examples to illustrate syntax, behavior, and scope.

=== MySQL ===

Session variables in MySQL have syntax similar to the better-known T-SQL variables (though other details are MySQL-specific). MySQL distinguishes two kinds of variables:

system variables - referenced using the `@@` prefix (or `@@scope.name`)
user-defined variables - referenced using the `@` prefix

System variables are modified with the `SET` statement. The `SET` statement accepts the modifiers `GLOBAL`, `SESSION`, or `PERSIST`. Some variables can only be set using the `GLOBAL` or `SESSION` modifier; when the variable name is specified with the `@@` prefix, it is not necessary to explicitly indicate the scope. System variables are defined by MySQL or by MySQL plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysqld-auto.cnf` (in the server data directory).

Resetting system variables can be done by assigning DEFAULT or by copying from the GLOBAL namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalents:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User-defined variables are created by assignment:

SET @var = expr [, @var2 = expr [ ... ]];

User-defined variables can only be of type integer, decimal, float, binary, non-binary string, or NULL. Casting between these types is implicit and hidden. User-defined variables cannot be used as table or column names.

An advantage of the T-SQL-style syntax (with special prefixes) is that it provides a simple solution for avoiding identifier collisions. MySQL variables are convenient, and the user experience can be good for people already familiar with T-SQL (MSSQL or Sybase). On the other hand, prefix-based syntax can be confusing for users coming from systems other than MSSQL. The type system is perhaps too simple and can be unsafe. In general, the performance of MySQL (or MariaDB) stored procedures is not good, and stored procedures are therefore not frequently used. There is no protection against typographical errors. Unassigned user variables can be used without error (they default to NULL), which makes static checking of stored procedures impossible in this area.

There is no way to restrict access to user-defined variables in MySQL. They cannot be protected against unintended usage. The only possible safeguard is a naming convention, since all user-defined variables share a single namespace.

=== Oracle ===

Oracle PL/SQL allows the use of package variables. PL/SQL is based on the Ada language, and package variables act as "global" variables. They are not directly visible from SQL, but Oracle provides a reduced syntax for functions without arguments, so you typically write a wrapper:

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL, SQL identifiers take precedence. Inside non-SQL commands (such as CALL or PL/SQL blocks), package identifiers take precedence.

Oracle allows both syntaxes for calling a function with zero arguments:

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

This reduces the risk of naming collisions. Package variables persist for the duration of a session.

Another possibility is to use variables in SQL*Plus (similar to `psql` variables, but with the ability to define the type on the server side).

A variable is declared with the `VARIABLE` command and can be accessed in the session using the `:varname` syntax (a prior declaration step may be optional):

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

=== DB2 ===

The "user-defined global variables" in DB2 are similar to the proposed PostgreSQL feature. The main difference is in the access rights: DB2 uses `READ` and `WRITE`, while PostgreSQL uses `SELECT` and `UPDATE`. Because PostgreSQL already uses the `SET` command for GUCs, the `LET` command was introduced in the proposal (DB2 uses `SET`).

Variables are visible in all sessions, but their values are private to each session. Variables are not transactional. Their usage is broader than in the proposal: they can be changed by `SET`, `SELECT INTO`, or used as OUT parameters of procedures. The search path (or a similar mechanism) applies to variables as well, but variables have lower priority than tables or columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = 'A00';
SET myCounter = 29;

There also appear to be other kinds of variables, accessed using the function `GETVARIABLE('name', 'default')`. These are very similar to PostgreSQL GUCs and the `current_setting` function. Such variables can be set via the connection string, are of type `VARCHAR`, and up to 10 values are allowed. Built-in session variables (configuration) can also be accessed using `GETVARIABLE`.

=== MSSQL (T-SQL) ===

MSSQL provides two types of variables:

* Global variables — accessed with the `@@varname` syntax. These are similar to GUCs and provide state information such as `@@ERROR`, `@@ROWCOUNT`, or `@@IDENTITY`.
* Local variables** — accessed with the `@varname` syntax. These must be declared with the `DECLARE` command before use. Their scope is limited to the batch, procedure, or function where they are executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails because `PRINT` is executed in a different batch. Therefore, it seems MSSQL does not truly support session variables.

There are also mechanisms similar to PostgreSQL's custom GUCs and the use of `current_setting` and `set_config` functions. In general, MSSQL is fairly primitive in this area.

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== ToDo ==

* SECURITY LABEL support — enhance the `dummy_seclabel` module and the `sepgsql` extension. Update PostgreSQL documentation and ensure `SecLabelSupportsObjectType` includes session variables.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

== Implementation issues ==
=== Collisions between columns and variables identifiers ===
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-28T06:00:41Z

Okbobcz: /* Implementation issues */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

== Implementation issues ==
=== Collisions between columns and variables identifiers ===
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
-- not implemented yet, not part of this proposal
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-28T05:59:55Z

Okbobcz: /* Collisions between columns and variables identifiers */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

== Implementation issues ==
=== Collisions between columns and variables identifiers ===
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap). The implementation of declared tables inside PL/pgSQL can be more easy from high design perspective (interaction between SQL tables and PL/pgSQL is well defined already), but difficult from low level perspective (where to store column statistics and other important data for optimization - same problems like with global temporary tables (without some fake proxy local temp tables)).

CREATE OR REPLACE FUNCTION fx()
AS $$
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-28T05:55:53Z

Okbobcz: /* Implementation issues */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

== Implementation issues ==
=== Collisions between columns and variables identifiers ===
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap).

CREATE OR REPLACE FUNCTION fx()
AS $$
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-28T05:54:46Z

Okbobcz: /* Collisions between columns and variables identifiers */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

== Implementation issues ==
=== Collisions between columns and variables identifiers ===
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap).

CREATE OR REPLACE FUNCTION fx()
AS $$
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-28T05:53:22Z

Okbobcz: /* Collisions between columns and variables identifiers */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

== Implementation issues ==
=== Collisions between columns and variables identifiers ===
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

A variable fence can be in collisions with custom function "variable". There is similarity with usage of keywords `cube`. This can be fixed by usage prefix schema or by usage of parenthesis:

SELECT public.variable(...)
SELECT "variable"(...)

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables. Similarly we can use `$` prefix, but then we can break query parameters syntax.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

Note: There was a proposal to use table syntax as variable (like table (in memory) variables from T-SQL but only single row). Although it is very effective solution of collisions, I dislike this idea. It increase a complexity of simple expression (or increase inconsistency of some syntax rules). More looks weird for scalar variables (and can be handy for composite variables):

CREATE VARIABLE var AS int;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(var); -- variable is not a table
END
$$;

CREATE VARIABLE var AS int;
DO $$
BEGIN
-- variable a a table (I don't like it)
-- can we use DML? How much rows this kind of variable can hold
-- value is row or not?
RAISE NOTICE '%', (SELECT var FROM var);
END
$$

I am not against for introduction of inmemory tables - or more correctly for global temporary tables. Well implemented global temporary tables can be very nice and handy feature. But it is different feature, and should be designed separately. There can be some performance problems - plpgsql can use simple expression evaluation (when expression has not usage of any table). This optimization can be changed or enhanced, but its is change inside complex sensitive code, and it is not consistent. I very like a global temporary tables (that are not implemented in Postgres). Table (and related operations) should to looks like table, variable (and related operations) should to looks like variable. Common perspective how session variables should to looks is based on variables from PL environment. PostgreSQL internally supports transition tables, and I can imagine to allow this kind of tables outside of triggers too. This is valid use case (and valid functionality), but it is something different than session variables (although there can be some overlap).

CREATE OR REPLACE FUNCTION fx()
AS $$
DECLARE t TABLE(a int, b int); -- this table is invisible outside fx
BEGIN
INSERT INTO t VALUES(10,20);
INSERT INTO t VALUES(30,40);
RAISE NOTICE '%', (SELECT count(*) FROM t);
END;
$$ LANGUAGE plpgsql;

Some data languages defined relational variables - common concept of session variables has zero intersection with this concept.

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-28T05:16:18Z

Okbobcz: /* Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

== Implementation issues ==
=== Collisions between columns and variables identifiers ===
There is a new possibility of identifiers collisions between variables and columns identifiers. With ANSI SQL syntax for session variables identifiers there is a problem how to distinct between variable and column. This is known problem in PL/pgSQL or PL/SQL and can be solved by some prioritization or by prohibition of collisions. The prohibition of collisions is solution that almost cleaned this issue from PL/pgSQL. Unfortunately session variables are global objects and then the collision can be in any query, and then the new badly named variable can stop execution of any query. Prioritization variables or columns has own problems - quiet unwanted using variable or column.

CREATE TABLE tab(a int);
CREATE VARIABLE a AS int;

SELECT a FROM tab; -- with disallowed collisions, the execution of this query stops when there is a variable named "a"

LET a = 1;
DELETE FROM tab WHERE a = 1; -- with higher priority for variables all table can be deleted (nobody proposed higher priority for variables).
SELECT a FROM tab; -- with higher priority for columns, the variable is not used (quietly)

The prohibition of collision is not absolute protection against possible human errors:

CREATE VARIABLE _id AS int;
LET _id = 10;
CREATE TABLE foo(id int);
DELETE FROM foo WHERE _id = 10; -- just type, but can have unwanted impact (all rows removed)

These problems are not new. The developers in PL/pgSQL or PL/SQL knows it, but the scope of these risks are limited only to stored procedures. After very very long discussion and lot of designs I introduced variable fences (syntax `VARIABLE(varname)`). Inside of any query the variable can be used only in variable fence. This is 100% solution of collisions, and I think it can be good solution against human errors and unwanted usage of session variable. Now, variable fences are necessary every where inside a query or expressions, but I thinking about possibility to be optional inside PL/pgSQL (far future). This can reduce overhead with porting applications from Oracle, and generally the developers of stored procedures are experienced with described risks (this can be controlled by new `plpgsql.extra_checks`).

Why I don't propose usage of T-SQL (MSSQL, MySQL) syntax for session variables? There is more reasons (one is objective, last is subjective):

* There is a collision with custom operators - operators `@` or `@@` are already used - usage of `@@` is common

(2025-09-28 06:57:30) postgres=# create table tab(a int);
CREATE TABLE
(2025-09-28 06:57:42) postgres=# insert into tab values(10);
INSERT 0 1
(2025-09-28 06:57:50) postgres=# select @a from tab;
┌──────────┐
│ ?column? │
╞══════════╡
│ 10 │
└──────────┘
(1 row)

We can safely use only `:` prefix, but then we can break a psql variables.

* T-SQL variable names looks weird in Postgres (in queries, in PL/pgSQL). Postgres knows only ANSI/SQL identifiers, PL/pgSQL shares these rules too, and this are the PostgreSQL is consistent, and I missing motivation to introduce something new (with the knowledge so problems with possible compatibility breaks should be solved too).

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-27T19:24:05Z

Okbobcz: /* Possible use cases */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems (mainly from Oracle)
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-27T19:13:39Z

Okbobcz: /* Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers */

= Session variables =
Session variables are database objects that can hold a value across multiple queries inside a session. A design of session variables is varied and more times more databases implement more than just one type of session variables. Unfortunately standard SQL/PSM is not commonly accepted, and a part of this standard related to modules and module's variables was not implemented (in any widely used product). Very often session variables are a part of the stored procedures environment - but there are exceptions (MySQL session variables or any client side session variables). What I know is that session variables don't support transactions (for values). It is a plus minus just variable like we know from programming languages.

There is no common design of session variables. Currently any database system has its own proprietary design with proprietary syntax and features. Some systems have more than one different design of session variables. It is hard to compare different designs - any design has different advantages and disadvantages.

== MySQL ==
Session variables in MySQL have the same syntax like more known T-SQL variables (but all other things are proprietary). MySQL knows two kinds of session variables:

* system variables - use the prefix `@@` or `@@xxx.`
* user defined variables - use the prefix `@`

System variables can be modified by command `SET`. After keyword `SET` keywords `GLOBAL`, `SESSION` or `PERSIST` can be used.
Some variables can be used just with keyword `GLOBAL` or `SESSION` and in this case, when the name is prefixed by `@@`, is not
necessary to specify scope. System variables are defined by MySQL or by an mysql's plugins.

SET GLOBAL some_config = 100;
SET @@same_config = 100;

SET SESSION sql_mode = 'TRADITIONAL';
SET @@sql_mode = 'TRADITIONAL';
SET @@SESSION.sql_mode = 'TRADITIONAL';
SET sql_mode = 'TRADITIONAL';

Persistent values are stored in `mysql-auto.conf`.

Reset of system variables can be done by setting to default or assigning from global namespace:

SET @@sql_mode = DEFAULT;
SET @@sql_mode = @@GLOBAL.sql_mode

PostgreSQL equivalent:

SET GLOBAL ; -- there is not similar command in Postgres
SET SESSION ; -- SET
SET PERSIST ; -- ALTER SYSTEM; SELECT pg_reload_conf();
SELECT @@var; -- SELECT current_setting('var);

User defined variables are defined by assignment

SET @var = expr [, @var2 = expr [ ... ]];

User defined variables can be only int, decimal, float, binary, nonbinary string or NULL - casting from/to any types is implicit and hidden.
UDV cannot be used as table or column names.

An advantage of T-SQL syntax (with special prefixes) is simple solution of possible identifier collisions. MySQL
variables are very handy too, and user experience can be good for people with knowledge of T-SQL (MSSQL or Sybase).
On the other hand, prefix based syntax can be disturbing for users who work with different systems than MSSQL. Type system
is maybe too simple and can be usafe. Generally the performance of MySQL (or MariaDB) stored procedures is not good,
and stored procedures are not frequently used. There is not any protection against typo errors. Unassigned user variables
can be used without error (have NULL value), so static check of stored procedures is not possible (in this area).

There is not any possibility how to limit an access to user defined variables in MySQL. UDV cannot be protected
against unwanted usage. Some protection can be only naming convention (all UDV share one name space).

==Postgres==
Postgres has relatively advanced client side session variables in `psql`. `psql`'s variables use prefix ':'. The implementation is simple. psql's parser reads tokens from input. When it gets a token related to a variable, then this token is replaced by a value of variable. Implemented syntax supports literal and identifier escaping. psql's variables can be used as an argument of the `\bind` command.

psql's variables are typeless client side variables available only inside `psql` or `pgbench`.

(2025-09-25 09:40:18) postgres=# \set myvar ahoj
(2025-09-25 09:40:33) postgres=# \echo :myvar
ahoj

(2025-09-25 09:41:14) postgres=# select :'myvar';
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

(2025-09-25 09:41:24) postgres=# select $1 \bind :myvar \g
┌──────────┐
│ ?column? │
╞══════════╡
│ ahoj │
└──────────┘
(1 row)

psql's command `\set` allows just simply string concatenation - but allows to execute shell command. When
query is executed by `\gset` command, then result is stored in psql variable.

(2025-09-25 09:41:40) postgres=# \set ctime `date`
(2025-09-25 09:43:55) postgres=# \echo :ctime
čt 25. září 2025, 09:43:55 CEST

'\set` command is too simple, and writing some complex operations is unreadable or not portable.

It is good enough for writing tests, but it is not generally available (probably nobody expects it), and it is not
accessible from server side (from stored procedures). There is not simple way, how to access psql variables from
anonymous block (proxy custom GUC variable is needed):

(2025-09-25 09:58:38) postgres=# \echo :myvar
ahoj
(2025-09-25 09:58:43) postgres=# select set_config('myvars.myvar', :'myvar', false);
┌────────────┐
│ set_config │
╞════════════╡
│ ahoj │
└────────────┘
(1 row)

(2025-09-25 10:00:27) postgres=# do $$ begin raise notice '%', current_setting('myvars.myvar'); end $$;
NOTICE: ahoj
DO

PostgreSQL has configuration GUC (Grand Unified Configuration) variables. These variables are primarily designed for PostgreSQL and PostgreSQL extensions configuration, but can be used as session variables (implicit, explicit, typeless). These variables can be set by command `SET` or by function `set_config`, and can be read by command `SHOW` or by function `current_setting`. GUC variables are designed for holding configuration parameters. When they are created from an internal API, then they can be protected for super users, hidden to common users, and can have assigned types (bool, memory, number, interval, string, enum) and values that can be checked before assign. The type system is independent of the PostgreSQL SQL type system - it is used for configuration and that is processed before postgresql sql type system is initialized.

Variables created from SQL should be only "custom". The name of these variables have to use a prefix and these variables are string only. These variables are commonly used as a workaround for missing server side session variables in Postgres (typeless unprotected unsecure session variables).

Specific feature of Postgres GUC (build-in or custom) is the possibility to specify scope transaction, session or function execution. Another functionality is to assign a default value of a specific parameter with some event - loading configuration, login to role, login to database, start some function. These features are nice for work with configuration, but can be very problematic when GUC variables are used as session variables.

CREATE OR REPLACE FUNCTION fx()
RETURNS void AS $$
BEGIN
RAISE NOTICE '%', current_setting('my.x');
END $$ LANGUAGE plpgsql SET my.x = 20;
CREATE FUNCTION
(2025-09-27 06:10:37) postgres=# SET my.x = 0; SELECT fx();
SET
NOTICE: 20
┌────┐
│ fx │
╞════╡
│ │
└────┘
(1 row)
(2025-09-27 06:10:39) postgres=# SHOW my.x;
┌──────┐
│ my.x │
╞══════╡
│ 0 │
└──────┘
(1 row)

GUC variables are transactional - without possibility to disable it.

(2025-09-27 06:17:31) postgres=# set my.x = 10;
SET
(2025-09-27 06:19:42) postgres=# begin;
BEGIN
(2025-09-27 06:19:46) postgres=# select set_config('my.x', '20', true);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:19:55) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

(2025-09-27 06:20:01) postgres=# commit;
COMMIT
(2025-09-27 06:20:11) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:13) postgres=# begin;
BEGIN
(2025-09-27 06:20:38) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:20:45) postgres=# rollback;
ROLLBACK
(2025-09-27 06:20:52) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 10 │
└──────┘
(1 row)

(2025-09-27 06:20:55) postgres=# begin;
BEGIN
(2025-09-27 06:22:36) postgres=# select set_config('my.x', '20', false);
┌────────────┐
│ set_config │
╞════════════╡
│ 20 │
└────────────┘
(1 row)

(2025-09-27 06:22:39) postgres=# commit;
COMMIT
(2025-09-27 06:22:42) postgres=# show my.x;
┌──────┐
│ my.x │
╞══════╡
│ 20 │
└──────┘
(1 row)

So there is no possibility to store to custom GUC some details about an error.

== Oracle ==
Oracle PL/SQL allows the use of package variables. PL/SQL is based on ADA
language - and package variables are "global" variables. They are not
directly visible from SQL, but Oracle allows reduced syntax for functions
without arguments, so you need to write a wrapper

CREATE OR REPLACE PACKAGE my_package
AS
FUNCTION get_a RETURN NUMBER;
END my_package;
/

CREATE OR REPLACE PACKAGE BODY my_package
AS
a NUMBER(20);

FUNCTION get_a
RETURN NUMBER
IS
BEGIN
RETURN a;
END get_a;
END my_package;

SELECT my_package.get_a FROM DUAL;

Inside SQL the higher priority has SQL, inside non SQL commands like CALL
or some PL/SQL command, the higher priority has packages.

The Oracle allows both syntax for calling function with zero arguments so

SELECT my_package.get_a FROM DUAL;

or

SELECT my_package.get_a() FROM DUAL;

Then there is less risk reduction of collision. Package variables persist
in session

Another possibility is using variables in SQL*Plus (looks like our psql
variables, with possibility to define type on server side)

The variable should be declared by command VARIABLE and can be accessed by
syntax :varname in session before usage (maybe this step is optional)

VARIABLE bv_variable_name VARCHAR2(30)
BEGIN
:bv_variable_name := 'Some Value';
END;

SELECT column_name
FROM table_name
WHERE column_name = :bv_variable_name;

== DB2 ==
The "user defined global variables" are similar to my proposal. The
differences are different access rights "READ, WRITE" x "SELECT, UPDATE".
Because PostgreSQL has SET command for GUC, I introduced LET command (DB2
uses SET)

Variables are visible in all sessions, but value is private per session.
Variables are not transactional. The usage is wider than my proposal. Then
can be changed by commands SET, SELECT INTO or they can be used like OUT
parameters of procedures. The search path (or some like that) is used for
variables too, but the variables has less priority than tables/columns.

CREATE VARIABLE myCounter INT DEFAULT 01;
SELECT EMPNO, LASTNAME, CASE WHEN myCounter = 1 THEN SALARY ELSE NULL END
FROM EMPLOYEE WHERE WORKDEPT = ’A00’;
SET myCounter = 29;

There are (I think) different kinds of variables - accessed by the function
GETVARIABLE('name', 'default) - it looks very similar ro our GUC and
`current_setting` function. These variables can be set by connection
string, are of varchar type and 10 values are allowed. Built-in session
variables (configuration) can be accessed by the function GETVARIABLE too.

== MSSQL (T-SQL) ==
global variables - the access syntax is @@varname, they are used like GUC
and little bit more - some state informations are there like @@ERROR,
@@ROWCOUNT or @@IDENTITY

local variables - the access syntax is @varname, and should be declared
before usage by DECLARE command. The scope is limited to batch or procedure
or function, where DECLARE command was executed.

DECLARE @TestVariable AS VARCHAR(100)
SET @TestVariable = 'Think Green'
GO
PRINT @TestVariable

This script fails, because PRINT is executed in another batch. So I think
so MSSQL doesn't support session variables

There are similar mechanisms like our custom GUC and usage current_setting
and set_config functions. Generally, in this area is MSSQL very primitive

EXEC sp_set_session_context 'user_id', 4;
SELECT SESSION_CONTEXT(N'user_id');

== SQL/PSM ==
Standard introduces a concept of modules that can be joined with schemas.
The variables are like PLpgSQL, but only local - the only temp tables can
be defined on module levels. These tables can be accessed only from
routines assigned to modules. Modules are declarative versions of our
extensions (if I understand well, I didn't find any implementation). It
allows you to overwrite the search patch for routines assigned in the
module. Variables are not transactional, the priority - variables/columns
is not specified.

= Types of different session variables =
* client side (psql, pgadmin, ...) - mostly similar to shell variables (based on string operations)
* server side
** declarative
*** created only for batch (T-SQL)
*** created as an database object (or part of database object) (Oracle, DB2)
** created by usage (MySQL)
** with special syntax (MySQL, T-SQL)
** with ANSI SQL syntax for identifiers (Oracle, DB2)

= Implementation of session variables in Postgres =

== Possible use cases ==
* usage of session variables as global variables in PL
* holding configuration (for PL)
* holding some more used data in interactive session
* holding credentials for some RLS and data securing
* helping with migration from others systems
* allow anonymous block parametrization (only postgres)

It is clean so no one design is perfect for all uses cases. MySQL is good enough and maybe handy for interactive work,
but cannot be used for storing any sensitive data, and it is unsafe. PostgreSQL GUC are perfect for configuration, but
are not friendly for interactive work, and are very limited for usage in PL as global variables. So no one design is
perfect, and I can imagine more different designs in one system, that can support some different use cases better.

== Proposal for Postgres - design session variables as database global temporary typed objects with ANSI SQL syntax for identifiers ==

I searched solution that can work with specific Postgres environment:

* Postgres has more than one widely used language for stored procedures PL/pgSQL + PL/Python or PL/Perl

* PL/pgSQL is strongly reduced PL/SQL, and PL/SQL is modified ADA language. I am pretty happy with the current scope of PL/SQL - it is domain specific language and it works well. It is a very simple language, and it is easy to learn it. PL/pgSQL has no packages or modules. Instead PostgreSQL schemas are used. But Postgres schemas are specific database objects. Schemas are independent on PL.

So I wanted design that can supports more PL languages, didn't introduce new complexity to relative simple PL/pgSQL and didn't introduce functionality that can be redundant with already existing objects.
I wrote bigger application in PL/pgSQL. For maintaining of this application I wrote plpgsql_lint (later plpgsql_check). So every time I am searching solution that doesn't block code static analyse. Static analyse requires persistent objects, and then it is direct way to design session variables as database objects (with own system catalog). When session variables are designed as database objects, then using ACL is natural. Oracle package variables are well protected just by package scope. Unfortunately, postgres doesn't know schema scope. The locality of schema objects is defined by setting of SEARCH_PATH guc, and introduction of new mechanism can be messy. But with ACL the content of variables can be safe too:

CREATE TEMP VARIABLE x AS int;

LET x = 10;
DO $$
BEGIN
RAISE NOTICE '%', VARIABLE(x);
END;
$$;

SELECT VARIABLE(x);

=Issues that any implementation should to solve =
* possible collision between session variables and other database objects
* memory cleaning after dropping session variable (when DDL can be reverted)
* memory invalidation (variable is dropped by one session, but still used in second session)

= ToDo =
* SECURITY LABEL support - enhancing dummy_seclabel module, sepgsql extension + pg doc and SecLabelSupportsObjectType

Implementation of declarative catalog session variables

2025-09-27T18:46:08Z

Okbobcz: /* Proposal for Postgres - design session variables as global temporary typed objects with ANSI SQL syntax for identifiers */

Implementation of declarative catalog session variables

2025-09-27T18:45:32Z

Okbobcz: /* Possible use cases */

Implementation of declarative catalog session variables

2025-09-27T18:41:07Z

Okbobcz: /* Possible use cases */

Implementation of declarative catalog session variables

2025-09-27T18:39:52Z

Okbobcz:

Implementation of declarative catalog session variables

2025-09-27T05:32:15Z

Okbobcz: /* Oracle */

Implementation of declarative catalog session variables

2025-09-27T05:31:44Z

Okbobcz: /* Session variables */

Implementation of declarative catalog session variables

2025-09-27T04:30:32Z

Okbobcz:

Implementation of declarative catalog session variables

2025-09-25T08:03:28Z

Okbobcz: /* Postgres */

Implementation of declarative catalog session variables

2025-09-25T08:02:42Z

Okbobcz: /* Postgres */

Implementation of declarative catalog session variables

2025-09-25T08:02:09Z

Okbobcz:

Implementation of declarative catalog session variables

2025-09-25T05:08:58Z

Okbobcz: /* MySQL */

Implementation of declarative catalog session variables

2025-09-25T04:44:04Z

Okbobcz: /* MySQL */

Implementation of declarative catalog session variables

2025-09-24T19:25:20Z

Okbobcz:

Implementation of declarative catalog session variables

2025-09-24T18:16:11Z

Okbobcz: /* Session variables */