Re: RFC: extensible planner state

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Aug 19, 2025 at 1:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> * The initial allocations of the arrays need to take
>> more care than this about which context the arrays go into,
>> ie it had better be planner_cxt for PlannerInfo or PlannerGlobal,
>> and the same context the RelOptInfo is in for RelOptInfo.
>> Otherwise you risk a mess under GEQO.

> It's easy to do this for PlannerInfo, but PlannerGlobal has no
> planner_cxt member. GetMemoryChunkContext() could be used but I'm not
> sure we want to spread reliance on that to more places. What's your
> thought?

You'll presumably have to use GetMemoryChunkContext() for RelOptInfo,
so I don't see much downside from using it in one or even both of the
other cases too.

>> * Surely, if extension_state etc is read_write_ignore, then
>> extension_state_allocated etc had better be as well? I don't
>> understand the rationale for preserving one without the other.

> I figured we can't print a void** but we can print an integer and the
> user might want to see it. Wrong idea?

Hm. We don't have read support for these structs, so maybe it's fine.
It looks weird though.

regards, tom lane