On Tue, Aug 4, 2026 at 7:48 AM Corey Huinker <[email protected]> wrote: > There has been some time for v19 dust to settle, so I've taken the work I had > done in the v2 patch set above, re-based that, and modified the end result to > use named parameters over arg arrays of differing lengths depending on the > purpose per Fujita-san's work, and tried to keep those changes in the same > very small layered steps for easier reviewing.
Thanks for working on this! As I said before, this is a pretty large change (and is actually an issue since v18 in part), so it's too late to do it at this stage. IIUC we are nearing the end of the stabilization phase for v19. I took a quick look at some patches: > Patches 0001-0003: Rename the argnum enum values to have a common prefix > (RELARG_, ATTARG_, EXTARG_) Do we really need this change? If not, I think that that would result in just making back-patching hard. This applies to all the changes, not just this one, but to make it easy, we need to consider the consistency across versions as much as possible. > Patch 0009: Stop treating "version" as a special-case parameter and add it to > the StatsArgInfo arrays. +1, but I'd separate this from the patch series, as it's a different improvement than removing the LOCAL_FCINFO call from SQL functions for stats import like pg_restore_relation_stats. > Patch 0011: Change the "internal" update functions to stop using the arg > arrays (of which some values are now empty because we've already resolved the > relation oid, etc) and instead use named NullableDatum parameters, like the > import_*_statistics() functions. I'm not sure this is really a good idea, as it's easier to use the arg arrays than the NullableDatum parameters, which also minimizes the differences between versions (including future versions), making back-patching easy. That's all I have for now. Best regards, Etsuro Fujita
