Comparing changes

This table holds metadata about session variables created by command CREATE VARIABLE, and dropped by command DROP VARIABLE.

Implementation of commands: CREATE VARIABLE varname AS type DROP VARIABLE varname ALTER VARIABLE varname OWNER TO ALTER VARIABLE varname RENAME TO ALTER VARIABLE varname SET SCHEMA ALTER command uses already prepared infrastructure based on ObjectAddress API, so this patch implements ObjectAddress related functionality too. Event triggers for DDL over session variables are supported.

Access to session variables can be controlled by SELECT or UPDATE rights. Both rights are introduced by this patch too. Default ACL are supported.

This patch enhancing psql to support session variables: * \dV[+] command * tab complete for CREATE, DROP, ALTER VARIABLE Note: tab complete for variable fencing is not supported yet

This patch enhancing pg_dump to support 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).

…ss functions Session variables are stored in session memory in a dedicated hash table. They are set by the LET command and read by the SELECT command. The access rights should be checked. Hash entries related to dropped session variables are not released. The memory cleaning is implemented in memory-cleaning-after-DROP-VARIABLE patch.

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

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.

This is a function designed for testing and debugging. It returns the content of sessionvars as-is, and can therefore display entries about session variables that were dropped but for which this backend didn't process the shared invalidations yet.

Implementation of DISCARD VARIABLES commands by removing hash table with session variables and resetting related memory context.

Accepting a sinval message invalidates entries in the "sessionvars" hash table. These entries are validated before any read or write operations on session variables. When the entry cannot be validated, it is removed. Removal will be delayed when the variable was dropped by the current transaction, which could still be rolled back.

set of plpgsql related tests: * check session variables and plpgsql variables are not in collision ever * check correct plpgsql plan cache invalidation when session variable is dropped * check so the value of session variable is not corrupted, when the variable is modified inside nested called functions

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/CAFj8pRAhnp63fV5m7ATr2_nW9_yVbFzwhL4Be8oTY_M0jksrXg@mail.gmail.com Author(s): Pavel Stehule

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Aug 9, 2025

This comparison is taking too long to generate.

Uh oh!