Horton

Re: Re: proposal: schema variables

jian he <jian.universality@gmail.com>

View thread
From: jian he <jian.universality@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Erik Rijkers <er@xs4all.nl>, Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, DUVAL REMI <REMI.DUVAL@cheops.fr>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-01-05T04:52:15Z
Lists: pgsql-hackers, pgsql-performance

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move WAL sequence code into its own file

  2. Add ExplainState argument to pg_plan_query() and planner().

  3. Don't include access/htup_details.h in executor/tuptable.h

  4. Refactor to avoid code duplication in transformPLAssignStmt.

  5. Avoid including commands/dbcommands.h in so many places

  6. Restrict psql meta-commands in plain-text dumps.

  7. Split func.sgml into more manageable pieces

  8. Fix squashing algorithm for query texts

  9. EXPLAIN: Always use two fractional digits for row counts.

  10. Preliminary refactoring of plpgsql expression construction.

  11. plpgsql: pure parser and reentrant scanner

  12. Add some sanity checks in executor for query ID reporting

  13. Fix misleading error message context

  14. Add macros for looping through a List without a ListCell.

diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
index 9c2957eb546..624858db301 100644
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -361,6 +361,9 @@ typedef struct Const
  * of the `paramid' field contain the SubLink's subLinkId, and
  * the low-order 16 bits contain the column number.  (This type
  * of Param is also converted to PARAM_EXEC during planning.)
+ *
+ * PARAM_VARIABLE:  The parameter is a reference to a session variable
+ * (paramid holds the variable's OID).
  */
 typedef enum ParamKind
 {
@@ -368,6 +371,7 @@ typedef enum ParamKind
  PARAM_EXEC,
  PARAM_SUBLINK,
  PARAM_MULTIEXPR,
+ PARAM_VARIABLE,
 } ParamKind;

 typedef struct Param
@@ -380,6 +384,10 @@ typedef struct Param
  int32 paramtypmod pg_node_attr(query_jumble_ignore);
  /* OID of collation, or InvalidOid if none */
  Oid paramcollid pg_node_attr(query_jumble_ignore);
+ /* OID of session variable if it is used */
+ Oid paramvarid;
+ /* true when param is used like base node of assignment indirection */
+ bool parambasenode;
  /* token location, or -1 if unknown */
  ParseLoc location;
 } Param;

comment should be "(paramvarid holds the variable's OID)"
also
+ /* true when param is used like base node of assignment indirection */
is kind of hard to understand.
param->parambasenode = true;
only happens in transformLetStmt so we can change it to
+ /* true when param is used in part of the LET statement.*/


--- a/src/include/executor/execdesc.h
+++ b/src/include/executor/execdesc.h
@@ -51,6 +51,10 @@ typedef struct QueryDesc
  /* This field is set by ExecutePlan */
  bool already_executed; /* true if previously executed */

+ /* reference to session variables buffer */
+ int num_session_variables;
+ SessionVariableValue *session_variables;
+
  /* This is always set NULL by the core system, but plugins can change it */
  struct Instrumentation *totaltime; /* total time spent in ExecutorRun */
 } QueryDesc;
QueryDesc->num_session_variables and
QueryDesc->session_variables are never used in 0001 and 0002.
it may be used in later patches,
but at least 0001 and 0002, we don't need to change
struct QueryDesc?


contrib/postgres_fdw/deparse.c
There are some cases of "case T_Param:"
do we need to do something on it?
also on src/backend/nodes/queryjumblefuncs.c, one
appearance of "case T_Param:". (but it seems no need change here)



CREATE VARIABLE v1 AS int;
CREATE VARIABLE v2 AS int;
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
select count(*) from tenk1 where unique1 = v1;
select count(*) from tenk1 where unique1 = v2;

should the last two queries be normalized as one query in pg_stat_statements?
if so, then maybe in typedef struct Param
we need change to:
Oid            paramvarid pg_node_attr(query_jumble_ignore);
but then
let v1 = v1+1;
let v1 = v2+1;
will be normalized as one query.