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 15:11:45 -0400
Message-ID: <CADkLM=cV=uezAKyZdyyxnZOBRhGLUSbeYfDj5_jbDCLP9LP24Q@mail.gmail.com> (raw)
In-Reply-To: <CADkLM=dxe8NbQu4RNi2OFXpaRKdpS0-CHGm6Mqtf_rW155BM4g@mail.gmail.com>
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>

On Tue, Jun 16, 2026 at 2:08 PM Corey Huinker <[email protected]>
wrote:

>
> 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.
>

Obviously, even that wouldn't get us to the no-FunctionCallInfo-at-all
goal, but it would get us out of the SPI situation. If we did have a
non-fcinfo function API, that API would either have to pass char *params
almost exclusively, or else each caller would have to do the translation or
float-array strings to double[] and such, which would be a lot of work for
the caller.

Would you be ok with a function like attribute_statistics_update, but
purely with cstring args? Obviously the callers would have to modify their
calls each time a new stat param is added, but that is seemingly preferable
for you than the current situation.

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=cV=uezAKyZdyyxnZOBRhGLUSbeYfDj5_jbDCLP9LP24Q@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