public inbox for [email protected]  

help / color / mirror / Atom feed

From: Corey Huinker <[email protected]>
To: Robert Haas <[email protected]>
Cc: Etsuro Fujita <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: use of SPI by postgresImportForeignStatistics
Date: Tue, 16 Jun 2026 14:08:51 -0400
Message-ID: <CADkLM=dxe8NbQu4RNi2OFXpaRKdpS0-CHGm6Mqtf_rW155BM4g@mail.gmail.com> (raw)
In-Reply-To: <CA+TgmoZpwfTGqqp=0efV99e_BMYWdLFq2XKRWVSDcukifkZMeA@mail.gmail.com>
References: <CA+TgmoYqMtWb4zLUkT98oFnEkJ=Wz0Pw-ggDJrp9wnSXPzUaeQ@mail.gmail.com>
	<CAPmGK161TJ4G01eptv3sBqgxa4SNHDE9VRqoC6jy5Y6G3D8yDw@mail.gmail.com>
	<CA+TgmoZpwfTGqqp=0efV99e_BMYWdLFq2XKRWVSDcukifkZMeA@mail.gmail.com>

On Tue, Jun 16, 2026 at 10:34 AM Robert Haas <[email protected]> wrote:

> On Tue, Jun 16, 2026 at 8:04 AM Etsuro Fujita <[email protected]>
> wrote:
> > I thought it would be a good idea to use
> > pg_restore_attribute_stats/pg_restore_relation_stats, because future
> > changes in attribute/relation stats would be absorbed by these
> > functions, which would lower the maintenance cost of this feature.
>
> I agree that we want to reuse code, but this isn't the right way to do
> it. For example, when we want to look up the OID of a relation from
> SQL, we can say 'whatever'::regclass::oid. But when we want to do the
> same thing from C, we don't construct a SELECT statement and execute
> it via SPI. Instead, we have functions like RangeVarGetRelidExtended()
> which provide access to the same underlying functionality more
> directly.
>
> Another example is converting strings to integers. The user calls
> int4in(), which then hands off the call to pg_strtoint32_safe(), which
> can also be called via pg_strtoint32(). Hence, C code should prefer to
> use pg_strtoint32(), while SQL will go through int4in(). Both
> ultimately reach the underlying pg_strtoint32_safe() function, but the
> interfaces are different, so that we can have it be suitable both for
> SQL access and for C access.
>
> This needs to work more like that. The underlying code that ingests
> and updates the stats should be shared, but the stuff that is specific
> to a FunctionCallInfo interface needs to be separated out so that we
> don't need to go through that when calling from C.
>
>
Back when pg_restore_attribute_stats and pg_restore_relation_stats were
being converted from positional to variadic functions, there was a patchset
or two (possibly un-posted, because I couldn't find it just now) where the
variadic functions re-marshalled the arguments into a call to a
fixed-parameter function. If that model were revived, we could have a more
conventional DirectFunctonCall() interface.

Is it possible that we never built a direct function call interface to a
variadic because we never needed one? Perhaps that time is now.

view thread (33+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: use of SPI by postgresImportForeignStatistics
  In-Reply-To: <CADkLM=dxe8NbQu4RNi2OFXpaRKdpS0-CHGm6Mqtf_rW155BM4g@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox