Remove the refint contrib module (for v20)

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

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

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

Hi Ayush,

I tested the v3 patch series on current HEAD.
For v3-0001, i verified that the refint extension files were removed
from contrib/spi, the related build system entries were updated, and
PostgreSQL built successfully after applying the patch. I also
confirmed that CREATE EXTENSION refint fails in a fresh database as
expected once the extension is removed.
For v3-0002, i verified that the patch applied cleanly and reviewed
the changes in AdjustUpgrade.pm. The added handling for upgrades from
versions older than v20, including dropping the refint extension and
its associated test tables during upgrade testing, looks correct. The
tree also built successfully with this patch applied.

I did not perform an actual cross-version pg_upgrade test, but the
patch series applied cleanly and behaved as expected in my testing.

Regards,
solai

Hello,

The doc patch says that Postgres 19 shipped a contrib module named
refint, but that's not fully correct. It shipped an *extension* named
refint inside the contrib module named spi. I think that wording could
be improved.

Regards

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

On 28 Jun 2026, at 10:14, Álvaro Herrera <alvherre@kurilemu.de> wrote:

The doc patch says that Postgres 19 shipped a contrib module named
refint, but that's not fully correct. It shipped an *extension* named
refint inside the contrib module named spi. I think that wording could
be improved.

Agreed.

+ trigger functions <function>check_primary_key()</function> and

We also typically don't append parentheses to function names in the docs.

--
Daniel Gustafsson

Hi,

On Mon, 29 Jun 2026 at 00:29, Daniel Gustafsson <daniel@yesql.se> wrote:

On 28 Jun 2026, at 10:14, Álvaro Herrera <alvherre@kurilemu.de> wrote:

The doc patch says that Postgres 19 shipped a contrib module named
refint, but that's not fully correct. It shipped an *extension* named
refint inside the contrib module named spi. I think that wording could
be improved.

Agreed.

+ trigger functions <function>check_primary_key()</function> and

We also typically don't append parentheses to function names in the docs.

Thanks for the review!

Attaching patch with improved wording and parentheses
changes.

Basic git diff between v3 and v4:

-  <title>refint Module Removed</title>
+  <title>refint Extension Removed</title>

-    PostgreSQL 19 and below shipped a
-    contrib module named refint that provided the
-    trigger functions check_primary_key() and
-    check_foreign_key() as an early way to enforce
+    PostgreSQL 19 and below shipped an
+    extension named refint, part of the
+    spi contrib module, providing the trigger
+    functions check_primary_key and
+    check_foreign_key as an early way to enforce

-    ...), and the module was removed
+    ...), and the extension was removed

Regards,
Ayush

On Sat, Jun 6, 2026 at 4:28 AM Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:

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.

In make-based contrib tests with USE_MODULE_DB=1, contrib/spi uses
contrib_regression_autoinc database, since autoinc is the first entry
in MODULES. So, in 0002 patch, shouldn't we also remove
the refint-related objects from contrib_regression_autoinc?

For example:

foreach my $dbname (
'contrib_regression_autoinc',
'contrib_regression_spi',
'regression_spi')
{
next unless $dbnames{$dbname};

_add_st(
$result,
$dbname,
'drop extension if exists refint cascade',
'drop table if exists pkeys, fkeys, fkeys2');
}

Regards,

--
Fujii Masao

Hi,

On Mon, 29 Jun 2026 at 11:53, Fujii Masao <masao.fujii@gmail.com> wrote:

On Sat, Jun 6, 2026 at 4:28 AM Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:

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.

In make-based contrib tests with USE_MODULE_DB=1, contrib/spi uses
contrib_regression_autoinc database, since autoinc is the first entry
in MODULES. So, in 0002 patch, shouldn't we also remove
the refint-related objects from contrib_regression_autoinc?

Thanks for the review, Fujii-san!

Yes, you are right, I missed removing that in 0002 patch.

v5-0001 is identical to v4-0001.

Adding you suggested changes, in v5.

Regards,
Ayush

Hi,

On Mon, 29 Jun 2026 at 11:53, Fujii Masao <masao.fujii@gmail.com> wrote:

On Sat, Jun 6, 2026 at 4:28 AM Ayush Tiwari <ayushtiwari.slg01@gmail.com>
wrote:

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.

In make-based contrib tests with USE_MODULE_DB=1, contrib/spi uses
contrib_regression_autoinc database, since autoinc is the first entry
in MODULES. So, in 0002 patch, shouldn't we also remove
the refint-related objects from contrib_regression_autoinc?

Thanks for the review!

Addressed in this thread:
/messages/by-id/CAJTYsWVMX_csjBafWngAqAAXBa=+Uy+rY2Je4jM6CJ11tF38Mw@mail.gmail.com

Regards,
Ayush

Committed.

--
nathan

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.

As you suggested, here's the back-branch doc change noting that refint
will be removed in v20, pointing users to the built-in foreign key
functionality.

I extended the existing paragraph (following the xml2/intagg deprecation
style) rather than adding a separate note. Intended for back-patch to all
supported branches (13-19).

Thoughts?

Regards,
Ayush

On 15 Jul 2026, at 15:47, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:

As you suggested, here's the back-branch doc change noting that refint
will be removed in v20, pointing users to the built-in foreign key
functionality.

I extended the existing paragraph (following the xml2/intagg deprecation
style) rather than adding a separate note. Intended for back-patch to all
supported branches (13-19).

+1 on adding this to help users. Unless objected to I'll apply and backpatch
this all the way (which is 14).

--
Daniel Gustafsson