Re: use of SPI by postgresImportForeignStatistics

On Fri, Jun 19, 2026 at 9:45 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Jun 18, 2026 at 5:23 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)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.