On Thu, Jun 18, 2026 at 5:23 PM Corey Huinker <corey.huinker@gmail.com> wrote: > To be clear, this solves the SPI problem, but questions about the design of attribute_statistics_update() and relation_statistics_update() remain, but those concerns are now isolated within their respective files attribute_stats.c and relation_stats.c. The inefficiencies therein aren't really in a critical path, so if we wanted to leave them be until v20 they could, but if time allows I'd at least like try unwinding some of that. But first, let's get SPI out of postgres_fdw.c.
I think that's the right order of priority, but I don't think that having import_attribute_statistics construct an fcinfo is great.
Me either, I'm looking at "phase 2" already where relation/attribute_statistics_update becomes a conventional function, and pg_clear_attribute_stats and pg_restore_attribute_stats (and their relstats equivalents) marshal their parameters to call that instead.
Ideally, attribute_statistics_update would call import_attribute_statistics rather than the other way around.
I think we're mostly on the same page. If we require the caller to understand the stats data structures to a greater level of detail, and require it to do the transformations to the proper input types (BlockNumbers, floats, float arrays, cstrings for anyarray, etc), then the import_attribute_statistics functon and the new attribute_statistics_update would be one-in-the-same. The v1 patch leaned heavily (perhaps too far) towards letting the caller pass along string values fetched via PQgetvalue() from a pg_stats without modification.
