public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Build whole-row Vars the same way during parsing and planning. 6+ messages / 1 participants [nested] [flat]
* pgsql: Build whole-row Vars the same way during parsing and planning. @ 2025-03-12 15:48 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-12 15:48 UTC (permalink / raw) To: [email protected] Build whole-row Vars the same way during parsing and planning. makeWholeRowVar() has different rules for constructing a whole-row Var depending on the kind of RTE it's representing. This turns out to be problematic because the rewriter and planner can convert view RTEs and set-returning-function RTEs into subquery RTEs; so a whole-row Var made during planning might look different from one made by the parser. In isolation this doesn't cause any problem, but if a query contains Vars made both ways for the same varno, there are cross-checks in the executor that will complain. This manifests for UPDATE, DELETE, and MERGE queries that use whole-row table references. To fix, we need makeWholeRowVar() to produce the same result from an inlined RTE as it would have for the original. For an inlined view, we can use RangeTblEntry.relid to detect that this had been a view RTE. For inlined SRFs, make a data structure definition change akin to commit 47bb9db75, and say that we won't clear RangeTblEntry.functions until the end of planning. That allows makeWholeRowVar() to repeat what it would have done with the unmodified RTE. Reported-by: Duncan Sands <[email protected]> Reported-by: Dean Rasheed <[email protected]> Diagnosed-by: Tender Wang <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/f4e7756ef9a437f30a4dc5ded41b8824a9d291b9 Modified Files -------------- src/backend/nodes/makefuncs.c | 51 ++++++++++++++++++++++++-- src/backend/optimizer/prep/prepjointree.c | 10 ++++-- src/test/regress/expected/returning.out | 60 ++++++++++++++++++++++++++++++- src/test/regress/sql/returning.sql | 24 +++++++++++++ 4 files changed, 140 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Build whole-row Vars the same way during parsing and planning. @ 2025-03-12 15:48 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-12 15:48 UTC (permalink / raw) To: [email protected] Build whole-row Vars the same way during parsing and planning. makeWholeRowVar() has different rules for constructing a whole-row Var depending on the kind of RTE it's representing. This turns out to be problematic because the rewriter and planner can convert view RTEs and set-returning-function RTEs into subquery RTEs; so a whole-row Var made during planning might look different from one made by the parser. In isolation this doesn't cause any problem, but if a query contains Vars made both ways for the same varno, there are cross-checks in the executor that will complain. This manifests for UPDATE, DELETE, and MERGE queries that use whole-row table references. To fix, we need makeWholeRowVar() to produce the same result from an inlined RTE as it would have for the original. For an inlined view, we can use RangeTblEntry.relid to detect that this had been a view RTE. For inlined SRFs, make a data structure definition change akin to commit 47bb9db75, and say that we won't clear RangeTblEntry.functions until the end of planning. That allows makeWholeRowVar() to repeat what it would have done with the unmodified RTE. Reported-by: Duncan Sands <[email protected]> Reported-by: Dean Rasheed <[email protected]> Diagnosed-by: Tender Wang <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ca0830e5a27a1a7e58bc62b4b7950c1bf96d882c Modified Files -------------- src/backend/nodes/makefuncs.c | 51 +++++++++++++++++++++++++-- src/backend/optimizer/prep/prepjointree.c | 10 ++++-- src/test/regress/expected/returning.out | 57 +++++++++++++++++++++++++++++++ src/test/regress/sql/returning.sql | 24 +++++++++++++ 4 files changed, 138 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Build whole-row Vars the same way during parsing and planning. @ 2025-03-12 15:48 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-12 15:48 UTC (permalink / raw) To: [email protected] Build whole-row Vars the same way during parsing and planning. makeWholeRowVar() has different rules for constructing a whole-row Var depending on the kind of RTE it's representing. This turns out to be problematic because the rewriter and planner can convert view RTEs and set-returning-function RTEs into subquery RTEs; so a whole-row Var made during planning might look different from one made by the parser. In isolation this doesn't cause any problem, but if a query contains Vars made both ways for the same varno, there are cross-checks in the executor that will complain. This manifests for UPDATE, DELETE, and MERGE queries that use whole-row table references. To fix, we need makeWholeRowVar() to produce the same result from an inlined RTE as it would have for the original. For an inlined view, we can use RangeTblEntry.relid to detect that this had been a view RTE. For inlined SRFs, make a data structure definition change akin to commit 47bb9db75, and say that we won't clear RangeTblEntry.functions until the end of planning. That allows makeWholeRowVar() to repeat what it would have done with the unmodified RTE. Reported-by: Duncan Sands <[email protected]> Reported-by: Dean Rasheed <[email protected]> Diagnosed-by: Tender Wang <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ae0be2f0bd726fd0f094279ab044b25e185b2ed2 Modified Files -------------- src/backend/nodes/makefuncs.c | 51 +++++++++++++++++++++++++-- src/backend/optimizer/prep/prepjointree.c | 10 ++++-- src/test/regress/expected/returning.out | 57 +++++++++++++++++++++++++++++++ src/test/regress/sql/returning.sql | 24 +++++++++++++ 4 files changed, 138 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Build whole-row Vars the same way during parsing and planning. @ 2025-03-12 15:48 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-12 15:48 UTC (permalink / raw) To: [email protected] Build whole-row Vars the same way during parsing and planning. makeWholeRowVar() has different rules for constructing a whole-row Var depending on the kind of RTE it's representing. This turns out to be problematic because the rewriter and planner can convert view RTEs and set-returning-function RTEs into subquery RTEs; so a whole-row Var made during planning might look different from one made by the parser. In isolation this doesn't cause any problem, but if a query contains Vars made both ways for the same varno, there are cross-checks in the executor that will complain. This manifests for UPDATE, DELETE, and MERGE queries that use whole-row table references. To fix, we need makeWholeRowVar() to produce the same result from an inlined RTE as it would have for the original. For an inlined view, we can use RangeTblEntry.relid to detect that this had been a view RTE. For inlined SRFs, make a data structure definition change akin to commit 47bb9db75, and say that we won't clear RangeTblEntry.functions until the end of planning. That allows makeWholeRowVar() to repeat what it would have done with the unmodified RTE. Reported-by: Duncan Sands <[email protected]> Reported-by: Dean Rasheed <[email protected]> Diagnosed-by: Tender Wang <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/fec43428c9662ad0217308529ef6cdd211e8b478 Modified Files -------------- src/backend/nodes/makefuncs.c | 51 +++++++++++++++++++++++++-- src/backend/optimizer/prep/prepjointree.c | 10 ++++-- src/test/regress/expected/returning.out | 57 +++++++++++++++++++++++++++++++ src/test/regress/sql/returning.sql | 24 +++++++++++++ 4 files changed, 138 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Build whole-row Vars the same way during parsing and planning. @ 2025-03-12 15:48 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-12 15:48 UTC (permalink / raw) To: [email protected] Build whole-row Vars the same way during parsing and planning. makeWholeRowVar() has different rules for constructing a whole-row Var depending on the kind of RTE it's representing. This turns out to be problematic because the rewriter and planner can convert view RTEs and set-returning-function RTEs into subquery RTEs; so a whole-row Var made during planning might look different from one made by the parser. In isolation this doesn't cause any problem, but if a query contains Vars made both ways for the same varno, there are cross-checks in the executor that will complain. This manifests for UPDATE, DELETE, and MERGE queries that use whole-row table references. To fix, we need makeWholeRowVar() to produce the same result from an inlined RTE as it would have for the original. For an inlined view, we can use RangeTblEntry.relid to detect that this had been a view RTE. For inlined SRFs, make a data structure definition change akin to commit 47bb9db75, and say that we won't clear RangeTblEntry.functions until the end of planning. That allows makeWholeRowVar() to repeat what it would have done with the unmodified RTE. Reported-by: Duncan Sands <[email protected]> Reported-by: Dean Rasheed <[email protected]> Diagnosed-by: Tender Wang <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d3a29ae6a60cba3d971cd184d477af8d17f157ee Modified Files -------------- src/backend/nodes/makefuncs.c | 51 +++++++++++++++++++++++++-- src/backend/optimizer/prep/prepjointree.c | 10 ++++-- src/test/regress/expected/returning.out | 57 +++++++++++++++++++++++++++++++ src/test/regress/sql/returning.sql | 24 +++++++++++++ 4 files changed, 138 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Build whole-row Vars the same way during parsing and planning. @ 2025-03-12 15:48 Tom Lane <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2025-03-12 15:48 UTC (permalink / raw) To: [email protected] Build whole-row Vars the same way during parsing and planning. makeWholeRowVar() has different rules for constructing a whole-row Var depending on the kind of RTE it's representing. This turns out to be problematic because the rewriter and planner can convert view RTEs and set-returning-function RTEs into subquery RTEs; so a whole-row Var made during planning might look different from one made by the parser. In isolation this doesn't cause any problem, but if a query contains Vars made both ways for the same varno, there are cross-checks in the executor that will complain. This manifests for UPDATE, DELETE, and MERGE queries that use whole-row table references. To fix, we need makeWholeRowVar() to produce the same result from an inlined RTE as it would have for the original. For an inlined view, we can use RangeTblEntry.relid to detect that this had been a view RTE. For inlined SRFs, make a data structure definition change akin to commit 47bb9db75, and say that we won't clear RangeTblEntry.functions until the end of planning. That allows makeWholeRowVar() to repeat what it would have done with the unmodified RTE. Reported-by: Duncan Sands <[email protected]> Reported-by: Dean Rasheed <[email protected]> Diagnosed-by: Tender Wang <[email protected]> Author: Tom Lane <[email protected]> Reviewed-by: Dean Rasheed <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/39af32f7883f5e3072aaa8b9c0c6bab7230ee3a3 Modified Files -------------- src/backend/nodes/makefuncs.c | 51 +++++++++++++++++++++++++-- src/backend/optimizer/prep/prepjointree.c | 10 ++++-- src/test/regress/expected/returning.out | 57 +++++++++++++++++++++++++++++++ src/test/regress/sql/returning.sql | 24 +++++++++++++ 4 files changed, 138 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-03-12 15:48 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-12 15:48 pgsql: Build whole-row Vars the same way during parsing and planning. Tom Lane <[email protected]> 2025-03-12 15:48 pgsql: Build whole-row Vars the same way during parsing and planning. Tom Lane <[email protected]> 2025-03-12 15:48 pgsql: Build whole-row Vars the same way during parsing and planning. Tom Lane <[email protected]> 2025-03-12 15:48 pgsql: Build whole-row Vars the same way during parsing and planning. Tom Lane <[email protected]> 2025-03-12 15:48 pgsql: Build whole-row Vars the same way during parsing and planning. Tom Lane <[email protected]> 2025-03-12 15:48 pgsql: Build whole-row Vars the same way during parsing and planning. Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox