On Thu, Aug 20, 2026 at 2:15 AM Corey Huinker <corey.huinker@gmail.com> wrote: >> IIUC I think what you are proposing here is: >> >> * Removing the construction of FCINFO from pg_restore_*_stats/import_* functions >> * Removing the special handling of the version parameter >> * Renaming the argnum enum values >> >> Am I right? If so, I think these are in the order of necessity, so I >> recommend re-splitting the patchset into the three parts in the order. >> I lowered the priority of the renaming, because 1) I don't make it a >> blocker for others, and 2) I want to see how it improves things on its >> own. > > That's what I'm proposing, but if you're saying that renaming the enums is not desirable, then my revised proposal would be to keep the existing enum, keep a strict ordering in the enum where all key/version parameters come before any actual stats values, thus allowing us to pass the stats-only portion of the nullabledatum array to the caller. We'd use an offset technique like we do filling out tuple values/isnull/replaces arrays where we always index by Anum_something - 1. > > 1. Remove special handling of version parameter, add it into existing StatsArgInfo structures. Not the highest priority, but doing it first remove the possibility of having to re-adjust subsequent changes related to the offset I'm proposing. > 2. Remove construction of of FCINFO, going with passing the latter portion of the positional NullableDatum array.
+1. My point is: this is actually a minor issue (that would probably be fine as it is), so we should fix it with minimal changes, not to make back-patching hard. In other words: if we can't do so, we should do nothing about it.
>> Also, as this is an improvement for v20, I recommend creating a new >> thread (and a new CF entry) for it. > > Doing so now. Normally I'd start a new thread, but this one isn't that long and carries a lot of context.
Thank you! I think that that will attract more attention from developers.
