Re: Remove fcinfo from statistics update internal functions

On Wed, Sep 02, 2026 at 10:57:15PM -0400, Corey Huinker wrote:
>> We are never going to add a new stats value in a import APIs on a
>> stable branch, as it touches the shape of the catalogs, but this kind
>
> That wasn't my concern. My concern was that somebody implements these
> functions for their own FDW extension, and then when Postgres N+1 comes out
> we've added a new stats type, but they don't notice because their code
> written for version N still compiles. The initializer macro below does
> alleviate my concern a bit.

I'm perhaps less concerned than you are on this point due to the
addition argument that happens not that many times. So, I choose
prefer the safety net of a clean default. My suspicion is that folks
doing out-of-core business with this code are knowledgeable enough
about the internals that they would detect the new fields, or they
would not work on this amound of stats details at all.

> Does that mean you're in favor of pushing the structs and postgres_fdw API
> change to v19 then?

Hmm. Adding Nathan in CC on this one for comment from the RMT. It's
rather low priority compared to all the open items I can see listed on
the wiki, but it's an option I find worth considering by the day. I
don't want to put more stress than necessary on the RMT regarding this
thread, though..

On a risk scale, the risk is close to zero here, still not completely
zero due to b345a554edf3 in postgres_fdw.c, where we should use do a
set_int32_arg()->set_uint32_arg() before import_relation_statistics()
to be completely consistent. There is no difference in
src/backend/statistics/ between HEAD and REL_19_STABLE, the new bound
checks for the range values are outside the code paths touched by
cc9a8eb112fa. So I am not really concerned about a cherry-pick of
cc9a8eb112fa to REL_19_STABLE.
--
Michael