Subject: Remove the refint contrib module (for v20)

From: Ayush Tiwari <[email-masked]>
Date: Sat, 6 Jun 2026 00:57:56 +0530

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], 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.
<https://www.postgresql.org/message-id/flat/CAJTYsWXU%2BfhuzrEd_bnrxyGH3%2Bny8QRQC2QHf3ws6s9iki3c2Q%40mail.gmail.com>

Regards,
Ayush

---

From: Nathan Bossart <[email-masked]>
Date: Fri, 5 Jun 2026 16:05:07 -0500

> reason to keep refint around?

+1.  Do we need an appendix-obsolete entry for the docs?

-- 
nathan

---

From: Daniel Gustafsson <[email-masked]>
Date: Sat, 6 Jun 2026 00:05:36 +0200

> On 5 Jun 2026, at 23:05, Nathan Bossart <[email-masked]> wrote:
> 

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

---

From: Tom Lane <[email-masked]>
Date: Fri, 05 Jun 2026 18:09:47 -0400

> 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

---

From: Ayush Tiwari <[email-masked]>
Date: Tue, 9 Jun 2026 00:44:21 +0530

Hi,

> backpatch) a mention to the docs that the functionality will be removed in

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

---

From: Ayush Tiwari <[email-masked]>
Date: Tue, 9 Jun 2026 10:16:37 +0530

Hi,

> split v2-0001 into 2 parts, one for removal and the other for appendix-

Rebasing.

Regards,
Ayush

---

From: Nathan Bossart <[email-masked]>
Date: Tue, 9 Jun 2026 15:42:35 -0500

>> resolving (mirrors the auth-radius pattern).  0002 is unchanged.

I'd likely combine these two before committing.

>> I can send it post this merge, as suggested.

Thanks.

> Rebasing.

LGTM

-- 
nathan

---

From: solai v <[email-masked]>
Date: Thu, 25 Jun 2026 16:58:36 +0530

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

---

From: Álvaro Herrera <[email-masked]>
Date: Sun, 28 Jun 2026 10:14:53 +0200

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/

---

From: Daniel Gustafsson <[email-masked]>
Date: Sun, 28 Jun 2026 20:59:38 +0200

> On 28 Jun 2026, at 10:14, Álvaro Herrera <[email-masked]> wrote:

> refint inside the contrib module named spi.  I think that wording could

Agreed.

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

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

--
Daniel Gustafsson

---

From: Ayush Tiwari <[email-masked]>
Date: Mon, 29 Jun 2026 10:11:06 +0530

Hi,

> 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

---

From: Fujii Masao <[email-masked]>
Date: Mon, 29 Jun 2026 15:23:28 +0900

>   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

---

From: Ayush Tiwari <[email-masked]>
Date: Mon, 29 Jun 2026 13:32:02 +0530

Hi,

> 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

---

From: Ayush Tiwari <[email-masked]>
Date: Mon, 29 Jun 2026 13:35:25 +0530

Hi,

Thanks for the review!

Addressed in this thread:
https://www.postgresql.org/message-id/CAJTYsWVMX_csjBafWngAqAAXBa%3D%2BUy%2BrY2Je4jM6CJ11tF38Mw%40mail.gmail.com

Regards,
Ayush

---

From: Nathan Bossart <[email-masked]>
Date: Wed, 8 Jul 2026 16:24:35 -0500

Committed.

-- 
nathan