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
signature.asc
Description: PGP signature
