Re: use of SPI by postgresImportForeignStatistics

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: use of SPI by postgresImportForeignStatistics
Date: 2026-06-30 01:10:41
Message-ID: CADkLM=f_c7Xoq-bSzw28LgvxPa+OQ3rVow=xwkTyjz1J0=pMdw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 29, 2026 at 2:17 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Jun 29, 2026 at 7:50 AM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
> wrote:
> > I like this refactoring, but while it's rather mechanical, it's pretty
> > large, so I think it's too late to do the refactoring at this time
> > just before the beta 2 release. So I'd vote for going with your
> > v1-0001 and v1-0002 and doing the refactoring in v20. As mentioned by
> > Robert, I don't think it's good to call LOCAL_FCINFO() in
> > import_relation_statistics() and import_attribute_statistics() to call
> > the guts of those functions either, but that is *consistent* with the
> > existing way pg_restore_relation_stats() and
> > pg_restore_attribute_stats() do that, so that is actually not that
> > bad. Also, as you mentioned above, it's inefficient for the new API
> > functions to lock an already-locked relation, and validate an
> > already-validated attname/attnum, but I think it would be negligible.

> Fujita-san, is it then your plan to get those two patches committed?

Are we ok with changing the functions that postgres_fdw makes from v19 to
v20? Because what I put in the v2 patch does not match the v1 patch. If we
are NOT ok with that, then we'd need to:

1. rename the two relation_stats_argnum -> relation_args_argnum and
attribute_stats_argnum -> attribute_args_argnum out of the way of the ones
created in relation_stats.h and attribute_stats.h. The actual enumeration
values can stay the same, as there are no conflicts there, just ambiguity
about which set of values they belong to.
2. rename the existing static functions relation_statistics_update ->
update_relstats and attribute_statistics_update -> update_relstats to make
way for the public functions of the same names.
3. Create new relation_statistics_update and attribute_statistics_update,
with the isnull/values, and have those fcinfo-invoke the respective
pg_restore functions just like v1 does.

That would at least make the user API consistent in v19 vs v20.

I'm on vacation this week, but time is short for beta2, so I'll make an
exception to get the above into beta2. Let me know if you want me to write
that up.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yilin Zhang 2026-06-30 01:20:20 Re:Re: COPY FROM with RLS
Previous Message Haibo Yan 2026-06-30 00:53:08 Re: Optimize UUID parse using SIMD