Horton

Thread

Commits

  1. Make SPI_prepare argtypes argument const

  2. Fixes for SPI "const Datum *" use

  3. Add support for importing statistics from remote servers.

  1. Make SPI_prepare argtypes argument const

    Peter Eisentraut <peter@eisentraut.org> — 2026-06-11T09:22:10Z

    This changes the argtypes argument of SPI_prepare(),
SPI_prepare_cursor(), SPI_cursor_open_with_args(), and
SPI_execute_with_args() from Oid *argtypes to const Oid *argtypes.
The underlying functions were already receptive to that, so this
doesn't require any significant changes beyond the function signatures
and some internal variables.

Commit 28972b6fc3dc recently introduced a case where a const had to be
cast away before calling these functions.  This is fixed here.

  2. Re: Make SPI_prepare argtypes argument const

    Ewan Young <kdbase.hack@gmail.com> — 2026-06-11T09:59:55Z

    Reviewed this. LGTM.

I checked that argtypes / param_types is only ever read or copied along
this path (never written or freed through the pointer), so const-qualifying
it is sound rather than merely tolerated. In particular CompleteCachedPlan()
palloc's its own copy and never retains the caller's array. pg_analyze_and_
rewrite_fixedparams() already takes const Oid *, so no further change is
needed there.

Applies cleanly on HEAD and builds without warnings here.

On Thu, Jun 11, 2026 at 5:22 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> This changes the argtypes argument of SPI_prepare(),
> SPI_prepare_cursor(), SPI_cursor_open_with_args(), and
> SPI_execute_with_args() from Oid *argtypes to const Oid *argtypes.
> The underlying functions were already receptive to that, so this
> doesn't require any significant changes beyond the function signatures
> and some internal variables.
>
> Commit 28972b6fc3dc recently introduced a case where a const had to be
> cast away before calling these functions.  This is fixed here.

  3. Re: Make SPI_prepare argtypes argument const

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-11T12:56:50Z

    Peter Eisentraut <peter@eisentraut.org> writes:
> This changes the argtypes argument of SPI_prepare(),
> SPI_prepare_cursor(), SPI_cursor_open_with_args(), and
> SPI_execute_with_args() from Oid *argtypes to const Oid *argtypes.

We've discussed that before, and held off because we weren't entirely
sure if anyone would complain that it is an API/ABI break.  I think
it's quite likely that the libabigail buildfarm machines will say
it is, but is there any actual consequence?

Also, if we are going to use const in SPI, there are more parameters
besides the datatype OIDs that could stand to be const-ified, eg
the various Datum/isnull arrays.

			regards, tom lane

  4. Re: Make SPI_prepare argtypes argument const

    Peter Eisentraut <peter@eisentraut.org> — 2026-06-11T18:35:22Z

    On 11.06.26 14:56, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> This changes the argtypes argument of SPI_prepare(),
>> SPI_prepare_cursor(), SPI_cursor_open_with_args(), and
>> SPI_execute_with_args() from Oid *argtypes to const Oid *argtypes.
> 
> We've discussed that before, and held off because we weren't entirely
> sure if anyone would complain that it is an API/ABI break.  I think
> it's quite likely that the libabigail buildfarm machines will say
> it is, but is there any actual consequence?

I don't think we are tracking ABI compatibility in unreleased branches?

One related thing I remember being discussed is adding qualifiers to 
functions that are part of the index or table access method APIs, 
because that breaks source code compatibility.  I don't think that kind 
of concern applies here.  (Also, I think we could still do those kinds 
of changes, but it'd be better to do them all at once in one release.)

> Also, if we are going to use const in SPI, there are more parameters
> besides the datatype OIDs that could stand to be const-ified, eg
> the various Datum/isnull arrays.

Those were already done, except that there were two curious stragglers, 
which I've added another patch to fix.

  5. Re: Make SPI_prepare argtypes argument const

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-06-11T18:57:01Z

    Peter Eisentraut <peter@eisentraut.org> writes:
> On 11.06.26 14:56, Tom Lane wrote:
>> We've discussed that before, and held off because we weren't entirely
>> sure if anyone would complain that it is an API/ABI break.  I think
>> it's quite likely that the libabigail buildfarm machines will say
>> it is, but is there any actual consequence?

> I don't think we are tracking ABI compatibility in unreleased branches?

True, it shouldn't really matter given we force people to recompile
extensions for new major versions.  SPI is an interface we expect
to hold stable across versions, but I can't see a reason that this
change would force extension source-code changes.

>> Also, if we are going to use const in SPI, there are more parameters
>> besides the datatype OIDs that could stand to be const-ified, eg
>> the various Datum/isnull arrays.

> Those were already done, except that there were two curious stragglers, 
> which I've added another patch to fix.

OK, no further concerns.

			regards, tom lane

  6. Re: Make SPI_prepare argtypes argument const

    Peter Eisentraut <peter@eisentraut.org> — 2026-06-30T13:54:52Z

    On 11.06.26 20:57, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> On 11.06.26 14:56, Tom Lane wrote:
>>> We've discussed that before, and held off because we weren't entirely
>>> sure if anyone would complain that it is an API/ABI break.  I think
>>> it's quite likely that the libabigail buildfarm machines will say
>>> it is, but is there any actual consequence?
> 
>> I don't think we are tracking ABI compatibility in unreleased branches?
> 
> True, it shouldn't really matter given we force people to recompile
> extensions for new major versions.  SPI is an interface we expect
> to hold stable across versions, but I can't see a reason that this
> change would force extension source-code changes.
> 
>>> Also, if we are going to use const in SPI, there are more parameters
>>> besides the datatype OIDs that could stand to be const-ified, eg
>>> the various Datum/isnull arrays.
> 
>> Those were already done, except that there were two curious stragglers,
>> which I've added another patch to fix.
> 
> OK, no further concerns.

It turned out that the second issue (the curious stragglers) were the 
result of an earlier PG19 commit.  So I have fixed that with a 
backpatch.  The argtypes one I have now committed to master.