Comparing changes

Introduce simple (non transactional) implementation of basic DDL statements. Because only temporary variables are allowed, we don't need a dedicated catalog. This is the most reduced version of declared session variables implementation. Main goal is introduction of basic functionality and reducing the size of the patch to maximum. This patch is designed to be possible to move to catalog based implementation without compatibility break. Some details about different implementations of session variables https://wiki.postgresql.org/wiki/Implementation_of_declarative_catalog_session_variables

The session variables can be used in query only inside the variable fence. This is special syntax VARIABLE(varname), that eliminates a risk of collision between variable and column identifier. The session variables cannot be used as parameters of CALL or EXECUTE commands. These commands evaluates arguments by direct call of expression executor, and direct access to session variables from expression executor will be implemented later (in next step)

In the plan stage we need to collect used session variables. On the order of this list, the param nodes gets paramid (fix_param_node). This number is used (later) as index to buffer of values of the used session variables. The buffer is prepared and filled by executor. Some unsupported optimizations are disabled: * parallel execution * simple expression execution in PL/pgSQL * SQL functions inlining Before execution of query with session variables we need to collect used session variables. This list is used for loading variables to executed query. plan

and locks variables used in query. Now we can read the content of any session variable. Direct reading from expression executor is not allowed, so we cannot to use session variables inside CALL or EXECUTE commands (can be supported with direct access to session variables (from expression executor) - postponed). Using session variables blocks parallel query execution. It is not technical problem (it just needs a serialization/deserialization of es_session_varibles buffer), but it increases a size of patch (and then it is postponed).

allows to store result of the query to session variable Check correct format of result - one column, one row.

The value is assigned to session variables usually by SET command. Unfortunately there are two reasons why SET should not be used for this purpose in Postgres. 1. Using a_expr inside generic_set ram rule produces reduce conflicts, so it needs total reimplementation of related gram rules. 2. SET is no plan command - so it doesn't support usage of parameters. 3. Excepting implementation issues, there is fact, so if we use SET command for assigning values to session variables, then there can be collisions between session variables and GUC, and then we need some concepts, how these collisions should be solved, or how to protect self against these collisions. With the dedicated command, the collisions between GUC and session variables are not possible. The command LET is executed as usual query execution. The result is stored to the target session variable (resultVariable) by using VariableDestReceiver. Implementations of EXPLAIN LET and PREPARE LET statements are not supported now. Postponed to next step due reducing patch size.

…ARIABLE, LET and VARIABLE()

Generally PostgreSQL DDL statements are transactional. We can implement transactional behave for ( CREATE | DROP ) VARIABLE too. Implementation is almost simple. DROP just set dropped_lxid, CREATE set created_lxid and moves previous entry of related sessionvars hashtab to stack. At the end of transaction for commit we just clean this stack. For rollback we do copy the bootom value from the stack and again clean stack.

If we support transactional DDL for CREATE, DROP session variables, we should to support subtransactions too. Implementation is simple. Any value has two new flags: created_subid and dropped_subid. At the subtransaction end for rollback we clean entries from the stack related to subtransactions. When commit we update created_subid and dropped_subid for parent subtransaction.

This branch was automatically generated by a robot using patches from an email thread registered at: https://commitfest.postgresql.org/patch/1608 The branch will be overwritten each time a new patch version is posted to the thread, and also periodically to check for bitrot caused by changes on the master branch. Patch(es): https://www.postgresql.org/message-id/CAFj8pRBH629MNqris2U4wyocNd0na5wv6czeUHRoTKYEH90-yA@mail.gmail.com Author(s): Pavel Stehule

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Apr 16, 2026

This comparison is taking too long to generate.

Uh oh!