Access root->simple_rte_array instead of Query->rtable for 2 more cases.
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t44284psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 04:58 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t44284_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t44284_1 && git checkout t44284_1Patchset v1 (message #1) is on t44284_1
When I am understanding the relationship between Query->rtable and
root->simple_rte_array, I'd like to assume that Query->rtable should be
never used
when root->simple_rte_array is ready. I mainly checked two places,
make_one_rel and
create_plan with the below hacks.
{
List *l = root->parse->rtable;
root->parse->rtable = NIL;
make_one_rel.. or create_plan_recurse..
root->parse->rtable = l;
}
Then I found adjust_appendrel_attrs_mutator and infer_arbiter_indexes still
use it. The attached patch fixed it by replacing the rt_fetch with
planner_rt_fetch,
all the tests passed.
--
Best Regards
Andy Fan (https://www.aliyun.com/)
Andy Fan <zhihui.fan1213@gmail.com> writes:
When I am understanding the relationship between Query->rtable and
root->simple_rte_array, I'd like to assume that Query->rtable should be
never used
when root->simple_rte_array is ready.
TBH, now that Lists are really arrays, there's basically no performance
advantage to be gained by fooling with this. I've considered ripping
out simple_rte_array, but haven't felt that the code churn would be
worth it.
regards, tom lane