diff options
author | Dean Rasheed <dean.a.rasheed@gmail.com> | 2025-01-16 14:57:35 +0000 |
---|---|---|
committer | Dean Rasheed <dean.a.rasheed@gmail.com> | 2025-01-16 14:57:35 +0000 |
commit | 80feb727c869cc0b2e12bd1543bafa449be9c8e2 (patch) | |
tree | 27fb43ef4b09067e3d725e1b918539d492a8550c /src/include/parser/parse_node.h | |
parent | 7407b2d48cf37bc8847ae6c47dde2164ef2faa34 (diff) | |
download | postgresql-80feb727c869cc0b2e12bd1543bafa449be9c8e2.tar.gz postgresql-80feb727c869cc0b2e12bd1543bafa449be9c8e2.zip |
Add OLD/NEW support to RETURNING in DML queries.
This allows the RETURNING list of INSERT/UPDATE/DELETE/MERGE queries
to explicitly return old and new values by using the special aliases
"old" and "new", which are automatically added to the query (if not
already defined) while parsing its RETURNING list, allowing things
like:
RETURNING old.colname, new.colname, ...
RETURNING old.*, new.*
Additionally, a new syntax is supported, allowing the names "old" and
"new" to be changed to user-supplied alias names, e.g.:
RETURNING WITH (OLD AS o, NEW AS n) o.colname, n.colname, ...
This is useful when the names "old" and "new" are already defined,
such as inside trigger functions, allowing backwards compatibility to
be maintained -- the interpretation of any existing queries that
happen to already refer to relations called "old" or "new", or use
those as aliases for other relations, is not changed.
For an INSERT, old values will generally be NULL, and for a DELETE,
new values will generally be NULL, but that may change for an INSERT
with an ON CONFLICT ... DO UPDATE clause, or if a query rewrite rule
changes the command type. Therefore, we put no restrictions on the use
of old and new in any DML queries.
Dean Rasheed, reviewed by Jian He and Jeff Davis.
Discussion: https://postgr.es/m/CAEZATCWx0J0-v=Qjc6gXzR=KtsdvAE7Ow=D=mu50AgOe+pvisQ@mail.gmail.com
Diffstat (limited to 'src/include/parser/parse_node.h')
-rw-r--r-- | src/include/parser/parse_node.h | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/src/include/parser/parse_node.h b/src/include/parser/parse_node.h index 0de44d166f4..994284019fb 100644 --- a/src/include/parser/parse_node.h +++ b/src/include/parser/parse_node.h @@ -295,6 +295,11 @@ struct ParseState * of SQL:2008 requires us to do it this way. We also use p_lateral_ok to * forbid LATERAL references to an UPDATE/DELETE target table. * + * While processing the RETURNING clause, special namespace items are added to + * refer to the OLD and NEW state of the result relation. These namespace + * items have p_returning_type set appropriately, for use when creating Vars. + * For convenience, this information is duplicated on each namespace column. + * * At no time should a namespace list contain two entries that conflict * according to the rules in checkNameSpaceConflicts; but note that those * are more complicated than "must have different alias names", so in practice @@ -312,6 +317,7 @@ struct ParseNamespaceItem bool p_cols_visible; /* Column names visible as unqualified refs? */ bool p_lateral_only; /* Is only visible to LATERAL expressions? */ bool p_lateral_ok; /* If so, does join type allow use? */ + VarReturningType p_returning_type; /* Is OLD/NEW for use in RETURNING? */ }; /* @@ -342,6 +348,7 @@ struct ParseNamespaceColumn Oid p_vartype; /* pg_type OID */ int32 p_vartypmod; /* type modifier value */ Oid p_varcollid; /* OID of collation, or InvalidOid */ + VarReturningType p_varreturningtype; /* for RETURNING OLD/NEW */ Index p_varnosyn; /* rangetable index of syntactic referent */ AttrNumber p_varattnosyn; /* attribute number of syntactic referent */ bool p_dontexpand; /* not included in star expansion */ |