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.Regards,
Ayush
