Remove the refint contrib module (for v20)
Hi,
This is intended for v20.
refint has long been documented as superseded by the built-in foreign
key mechanism, and the recent run of fixes (cascade-UPDATE NULL
crash, SQL-injection docs, removal of the broken private SPI plan
cache) suggests it's costing more to maintain than its sample-code
value justifies. On the plan-cache thread [1]PostgreSQL: [PATCH] refint: Avoid reusing cascade UPDATE plans. </messages/by-id/CAJTYsWXU+fhuzrEd_bnrxyGH3+ny8QRQC2QHf3ws6s9iki3c2Q@mail.gmail.com>, the idea of just
removing it in v20 came up and seemed to have some agreement, so
moving that to its own thread to discuss on its own terms.
The patch set is two pieces:
0001 removes refint:
- removes refint.c, refint.control, refint--1.0.sql, refint.example,
sql/refint.sql and expected/refint.out from contrib/spi/;
- drops refint from contrib/spi/Makefile and contrib/spi/meson.build,
the refint section from doc/src/sgml/contrib-spi.sgml, and the
now-unused EPlan typedef from src/tools/pgindent/typedefs.list.
0002 (test-only) teaches AdjustUpgrade.pm to drop the refint
extension and its leftover tables (pkeys, fkeys, fkeys2) from
contrib_regression_spi / regression_spi when upgrading from a version
that still shipped refint, so cross-version pg_upgrade tests don't
fail dump comparison once v20 opens.
I followed the existing < 19 btree_gist block style.
If we go ahead with this, a release-notes entry can land once
doc/src/sgml/release-20.sgml is created.
I can't run cross-version upgrade tests against v20 yet, so
the 0002 hunk would benefit from a look by someone with an xversion
buildfarm animal.
Thoughts? Does this look like the right approach, or is there a
reason to keep refint around?
[1]: PostgreSQL: [PATCH] refint: Avoid reusing cascade UPDATE plans. </messages/by-id/CAJTYsWXU+fhuzrEd_bnrxyGH3+ny8QRQC2QHf3ws6s9iki3c2Q@mail.gmail.com>
</messages/by-id/CAJTYsWXU+fhuzrEd_bnrxyGH3+ny8QRQC2QHf3ws6s9iki3c2Q@mail.gmail.com>
Regards,
Ayush
Attachments:
v1-0001-Remove-the-refint-contrib-module.patchapplication/octet-stream; name=v1-0001-Remove-the-refint-contrib-module.patchDownload+4-889
v1-0002-Handle-refint-removal-in-cross-version-pg_upgrade-te.patchapplication/octet-stream; name=v1-0002-Handle-refint-removal-in-cross-version-pg_upgrade-te.patchDownload+21-1
On Sat, Jun 06, 2026 at 12:57:56AM +0530, Ayush Tiwari wrote:
Thoughts? Does this look like the right approach, or is there a
reason to keep refint around?
+1. Do we need an appendix-obsolete entry for the docs?
--
nathan
On 5 Jun 2026, at 23:05, Nathan Bossart <nathandbossart@gmail.com> wrote:
On Sat, Jun 06, 2026 at 12:57:56AM +0530, Ayush Tiwari wrote:
Thoughts? Does this look like the right approach, or is there a
reason to keep refint around?+1. Do we need an appendix-obsolete entry for the docs?
Seems like a reasonable thing to add. Once merged, we should probably add (and
backpatch) a mention to the docs that the functionality will be removed in v20.
--
Daniel Gustafsson
Ayush Tiwari <ayushtiwari.slg01@gmail.com> writes:
Thoughts? Does this look like the right approach, or is there a
reason to keep refint around?
The only reason for refint to exist anymore is as example code,
but I think it's well short of our current standards, so it
really would need more work if we want to keep it. Some things
I'd want to see worked on if we keep it:
* The comments are not great
* Error handling is haphazard, eg inconsistent mix of elog and ereport
* After the cache-ectomy, it's hardly clear why it's still using
SPI_prepare rather than just SPI_execute_with_args
I doubt that anyone really wants to put in that work, so I'm
good with just removing it.
regards, tom lane
Hi,
On Sat, 6 Jun 2026 at 03:35, Daniel Gustafsson <daniel@yesql.se> wrote:
On 5 Jun 2026, at 23:05, Nathan Bossart <nathandbossart@gmail.com>
wrote:
On Sat, Jun 06, 2026 at 12:57:56AM +0530, Ayush Tiwari wrote:
Thoughts? Does this look like the right approach, or is there a
reason to keep refint around?+1. Do we need an appendix-obsolete entry for the docs?
Seems like a reasonable thing to add. Once merged, we should probably add
(and
backpatch) a mention to the docs that the functionality will be removed in
v20.
v2 attached. 0001 now adds an appendix-obsolete entry under the same
contrib-spi-refint id, so existing /current/ documentation links keep
resolving (mirrors the auth-radius pattern). 0002 is unchanged.
The back-patched "will be removed in v20" notice on v19 (and older)
I can send it post this merge, as suggested.
Please let me know if I've missed something more. Or if I should
split v2-0001 into 2 parts, one for removal and the other for appendix-
obsolete entry.
Regards,
Ayush
Attachments:
v2-0001-Remove-the-refint-contrib-module.patchapplication/octet-stream; name=v2-0001-Remove-the-refint-contrib-module.patchDownload+30-889
v2-0002-Handle-refint-removal-in-cross-version-pg_upgrade-te.patchapplication/octet-stream; name=v2-0002-Handle-refint-removal-in-cross-version-pg_upgrade-te.patchDownload+21-1
Hi,
On Tue, 9 Jun 2026 at 00:44, Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:
Hi,
On Sat, 6 Jun 2026 at 03:35, Daniel Gustafsson <daniel@yesql.se> wrote:
On 5 Jun 2026, at 23:05, Nathan Bossart <nathandbossart@gmail.com>
wrote:
On Sat, Jun 06, 2026 at 12:57:56AM +0530, Ayush Tiwari wrote:
Thoughts? Does this look like the right approach, or is there a
reason to keep refint around?+1. Do we need an appendix-obsolete entry for the docs?
Seems like a reasonable thing to add. Once merged, we should probably
add (and
backpatch) a mention to the docs that the functionality will be removed
in v20.v2 attached. 0001 now adds an appendix-obsolete entry under the same
contrib-spi-refint id, so existing /current/ documentation links keep
resolving (mirrors the auth-radius pattern). 0002 is unchanged.The back-patched "will be removed in v20" notice on v19 (and older)
I can send it post this merge, as suggested.Please let me know if I've missed something more. Or if I should
split v2-0001 into 2 parts, one for removal and the other for appendix-
obsolete entry.
Rebasing.
Regards,
Ayush
Attachments:
v3-0002-Handle-refint-removal-in-cross-version-pg_upgrade-te.patchapplication/octet-stream; name=v3-0002-Handle-refint-removal-in-cross-version-pg_upgrade-te.patchDownload+21-1
v3-0001-Remove-the-refint-contrib-module.patchapplication/octet-stream; name=v3-0001-Remove-the-refint-contrib-module.patchDownload+30-945
On Tue, Jun 09, 2026 at 10:16:37AM +0530, Ayush Tiwari wrote:
v2 attached. 0001 now adds an appendix-obsolete entry under the same
contrib-spi-refint id, so existing /current/ documentation links keep
resolving (mirrors the auth-radius pattern). 0002 is unchanged.
I'd likely combine these two before committing.
The back-patched "will be removed in v20" notice on v19 (and older)
I can send it post this merge, as suggested.
Thanks.
Rebasing.
LGTM
--
nathan