Make SPI_prepare argtypes argument const
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.
Attachments:
0001-Make-SPI_prepare-argtypes-argument-const.patchtext/plain; charset=UTF-8; name=0001-Make-SPI_prepare-argtypes-argument-const.patchDownload+32-27
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.
Show quoted text
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.
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
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.
Attachments:
v2-0001-Make-SPI_prepare-argtypes-argument-const.patchtext/plain; charset=UTF-8; name=v2-0001-Make-SPI_prepare-argtypes-argument-const.patchDownload+32-27
v2-0002-Add-some-more-const-qualifiers-to-SPI-functions.patchtext/plain; charset=UTF-8; name=v2-0002-Add-some-more-const-qualifiers-to-SPI-functions.patchDownload+6-7
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