-
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 18, 2025
-
Configuration menu - View commit details
-
Copy full SHA for 1aeb59e - Browse repository at this point
Copy the full SHA 1aeb59eView 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 ac6867f - Browse repository at this point
Copy the full SHA ac6867fView 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 12da13d - Browse repository at this point
Copy the full SHA 12da13dView 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 7462e50 - Browse repository at this point
Copy the full SHA 7462e50View 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 2593e1e - Browse repository at this point
Copy the full SHA 2593e1eView 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 82b299a - Browse repository at this point
Copy the full SHA 82b299aView commit details -
Configuration menu - View commit details
-
Copy full SHA for 213c661 - Browse repository at this point
Copy the full SHA 213c661View commit details -
Configuration menu - View commit details
-
Copy full SHA for 1a55a2b - Browse repository at this point
Copy the full SHA 1a55a2bView 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 2743a3b - Browse repository at this point
Copy the full SHA 2743a3bView 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 98ce3c3 - Browse repository at this point
Copy the full SHA 98ce3c3View 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 13b7379 - Browse repository at this point
Copy the full SHA 13b7379View 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 18, 2025 Configuration menu - View commit details
-
Copy full SHA for d382066 - Browse repository at this point
Copy the full SHA d382066View 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