On Mon, Dec 1, 2025 at 3:31 PM Robert Haas <[email protected]> wrote: > So I'm wondering if we ought to step back and rethink a bit. > subplanNames ensures that we assign a different name to every > PlannerInfo, but it doesn't give you any help finding the PlannerInfo > given the name, or enumerating all of the PlannerInfo objects that > exist. If we went back to allroots, and just fixed the problem of > temporary entries creeping into the list, the core code wouldn't > really notice the difference, but I think extensions would have an > easier time. > > Thoughts?
Here's a couple of patches to bring back allroots. The first one adds allroots, makes choose_plan_name() use it, and adds assertions that the contents of allroots and subplanNames correspond. The second one removes subplanNames. I imagine that these would be collapsed for commit, but testing 0001 without 0002 seems useful for peace of mind. -- Robert Haas EDB: http://www.enterprisedb.com
v1-0002-Remove-glob-subplanNames.patch
Description: Binary data
v1-0001-Add-a-list-of-all-PlannerInfo-roots-to-PlannerGlo.patch
Description: Binary data
