-
Notifications
You must be signed in to change notification settings - Fork 2
Comparing changes
Open a pull request
base repository: postgresql-cfbot/postgresql
base: cf/1608~1
head repository: postgresql-cfbot/postgresql
compare: cf/1608
- 12 commits
- 59 files changed
- 2 contributors
Commits on Dec 16, 2025
-
Configuration menu - View commit details
-
Copy full SHA for 8b4b0cf - Browse repository at this point
Copy the full SHA 8b4b0cfView commit details -
parsing session variable fences
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)
Configuration menu - View commit details
-
Copy full SHA for 4bd6b30 - Browse repository at this point
Copy the full SHA 4bd6b30View commit details -
collect session variables used in plan and assign paramid
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
Configuration menu - View commit details
-
Copy full SHA for c83b379 - Browse repository at this point
Copy the full SHA c83b379View commit details -
fill an auxiliary buffer with values of session variables used in query
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).
Configuration menu - View commit details
-
Copy full SHA for 3572192 - Browse repository at this point
Copy the full SHA 3572192View commit details -
allows to store result of the query to session variable Check correct format of result - one column, one row.
Configuration menu - View commit details
-
Copy full SHA for 7d44ac9 - Browse repository at this point
Copy the full SHA 7d44ac9View commit details -
LET command - assign a result of expression to the session variable
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.
Configuration menu - View commit details
-
Copy full SHA for 17d6d23 - Browse repository at this point
Copy the full SHA 17d6d23View commit details -
Configuration menu - View commit details
-
Copy full SHA for 954f76f - Browse repository at this point
Copy the full SHA 954f76fView commit details -
Configuration menu - View commit details
-
Copy full SHA for a42d13c - Browse repository at this point
Copy the full SHA a42d13cView commit details -
use names of currently used temp variables for tab complete of DROP V…
…ARIABLE, LET and VARIABLE()
Configuration menu - View commit details
-
Copy full SHA for 267b42f - Browse repository at this point
Copy the full SHA 267b42fView commit details -
transactional DDL - CREATE VARIABLE, DROP 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.
Configuration menu - View commit details
-
Copy full SHA for ca200ca - Browse repository at this point
Copy the full SHA ca200caView commit details -
subtransaction support for session variables DDL (CREATE, DROP)
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.
Configuration menu - View commit details
-
Copy full SHA for 1b59806 - Browse repository at this point
Copy the full SHA 1b59806View commit details -
[CF 1608] v20251215 - declarative session variables, LET command
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/CAFj8pRBsbg7pEFN3GC8hj_Y3DK08QONseteeZZXyaXk_G8QnyA@mail.gmail.com Author(s): Pavel Stehule
Commitfest Bot committedDec 16, 2025 Configuration menu - View commit details
-
Copy full SHA for 9d5d2e7 - Browse repository at this point
Copy the full SHA 9d5d2e7View commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff cf/1608~1...cf/1608