MIME-Version: 1.0
References: 
 <CA+TgmoYqMtWb4zLUkT98oFnEkJ=Wz0Pw-ggDJrp9wnSXPzUaeQ@mail.gmail.com>
 <CAPmGK161TJ4G01eptv3sBqgxa4SNHDE9VRqoC6jy5Y6G3D8yDw@mail.gmail.com>
 <CA+TgmoZpwfTGqqp=0efV99e_BMYWdLFq2XKRWVSDcukifkZMeA@mail.gmail.com>
 <CADkLM=dxe8NbQu4RNi2OFXpaRKdpS0-CHGm6Mqtf_rW155BM4g@mail.gmail.com>
 <CADkLM=cV=uezAKyZdyyxnZOBRhGLUSbeYfDj5_jbDCLP9LP24Q@mail.gmail.com>
 <CA+TgmoaVcgZJpwxyi7HEfNMJhmm7BXkTQ468jvxkW2QzQZRkvg@mail.gmail.com>
 <CADkLM=dy18dDJ+j3-_Ofn11vt5J7zF33oTWnE6N=ePc83uS91A@mail.gmail.com>
In-Reply-To: 
 <CADkLM=dy18dDJ+j3-_Ofn11vt5J7zF33oTWnE6N=ePc83uS91A@mail.gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
Date: Wed, 17 Jun 2026 19:23:07 +0900
Message-ID: 
 <CAPmGK15MfVT2H+PUvA_nAJvySGr_pAVkVx3KcnVXWGO36acWLA@mail.gmail.com>
Subject: Re: use of SPI by postgresImportForeignStatistics
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPmGK15MfVT2H%2BPUvA_nAJvySGr_pAVkVx3KcnVXWGO36acWLA%40mail.gmail.com>
Precedence: bulk

Hi Corey,

On Wed, Jun 17, 2026 at 7:50=E2=80=AFAM Corey Huinker <corey.huinker@gmail.=
com> wrote:
> I think the right first step is to create the functions import_relation_s=
tats() and import_attribute_stats() which take the oid of the destination r=
elation and the rest of the parameters are const char pointers, which is th=
e ideal case for a bunch of values being fetched from PQgetValue(). Those f=
unctions will for now just make the call to attribute_statistics_update() /=
 relation_statistics_update(), but at least it will be localized inside rel=
ation_stats.c and attribute_stats.c where we can make internal refactors wi=
thout disturbing anyone else.

+1

> Now, we *could* make these 2 new functions take the oid/oid+attname follo=
wed by a variadic array of keyname+value string pairs like the existing pg_=
restore_*_stats() functions, so the functions call signature would be somew=
hat future-proofed. Let me know if that violates your vision of what this s=
hould be.

IMO I don't think we need to go that far, because 1) the new functions
are provided for FDW authors only, and 2) we don't make changes to the
stats that often.

Thanks!

Best regards,
Etsuro Fujita