aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistproc.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-03-12 11:28:11 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2025-03-12 11:28:11 -0400
commit28a7e31d0cec07fdcea5f800cc29ed7b1ec04cfd (patch)
tree5318faafc5d545a6f1c95bb523f54a034b1aa5ca /src/backend/access/gist/gistproc.c
parentf5b4a0b49e0b0673adfa4366c3c1f49db6ec967f (diff)
downloadpostgresql-28a7e31d0cec07fdcea5f800cc29ed7b1ec04cfd.tar.gz
postgresql-28a7e31d0cec07fdcea5f800cc29ed7b1ec04cfd.zip
Preserve RangeTblEntry.relid when expanding a view RTE.
When the rewriter converts an RTE_RELATION RTE for a view into an RTE_SUBQUERY RTE containing the view's defining query, leave the relid field alone instead of zeroing it. This allows the planner to tell that the subquery came from a view rather than having been written in-line, which is needed to support an upcoming planner bug fix. We cannot change the behavior of the outfuncs/readfuncs code in released branches, so the relid field will not survive in plans passed to parallel workers; therefore this info should not be relied on in the executor. This back-patches a portion of the data structure definitional changes made in v16 and up by commit 47bb9db75. It's being committed separately for visibility in the commit log, but with luck it will not actually matter to anyone. While it's not inconceivable that this change will break code expecting relid to be zero in a subquery RTE, we can hope that such code has already been adjusted to cope with v16 and up. Reported-by: Duncan Sands <duncan.sands@deepbluecap.com> Diagnosed-by: Tender Wang <tndrwang@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Dean Rasheed <dean.a.rasheed@gmail.com> Discussion: https://postgr.es/m/3518c50a-ab18-482f-b916-a37263622501@deepbluecap.com Backpatch-through: 13-15
Diffstat (limited to 'src/backend/access/gist/gistproc.c')
0 files changed, 0 insertions, 0 deletions