{heap,minimal}_expand_tuple() are unused
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253347psql -h localhost -U postgresBuilt from patchset v4 (message #4), October 22, 2026 at 09:42 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253347_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253347_4 && git checkout t253347_4Patchset v4 (message #4) is on t253347_4
Hi,
As of
commit 20d3fe9009d
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: 2020-10-26 11:36:53 -0400
In INSERT/UPDATE, use the table's real tuple descriptor as target.
heap_expand_tuple() is unused. The use before that commit was short-lived
(ba9f18abd). Before that it was unused, since
commit 171e0418b03
Author: Andres Freund <andres@anarazel.de>
Date: 2019-02-06 01:09:32 -0800
Fix heap_getattr() handling of fast defaults.
As of
commit 4da597edf1b
Author: Andres Freund <andres@anarazel.de>
Date: 2018-11-16 16:35:11 -0800
Make TupleTableSlots extensible, finish split of existing slot type.
minimal_expand_tuple() is unused.
Both heap_expand_tuple() and minimal_expand_tuple() being unused, make
expand_tuple() unused in turn.
I think we probably ought to remove all three in 20? I didn't find external
callers. It's nontrivial enough code that I don't think we should keep it
around just because somebody might be using it.
Thoughts?
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
Both heap_expand_tuple() and minimal_expand_tuple() being unused, make
expand_tuple() unused in turn.
I think we probably ought to remove all three in 20? I didn't find external
callers. It's nontrivial enough code that I don't think we should keep it
around just because somebody might be using it.
+1. We can always get the code back out of git if a use-case
emerges.
regards, tom lane
Andres Freund <andres@anarazel.de> writes:
Both heap_expand_tuple() and minimal_expand_tuple() being unused, make
expand_tuple() unused in turn.
I think we probably ought to remove all three in 20? I didn't find external
callers. It's nontrivial enough code that I don't think we should keep it
around just because somebody might be using it.
... BTW, upon looking at the code coverage report to confirm these
are unused, I noticed that the adjacent heap_copytuple_with_tuple is
also unreferenced.
regards, tom lane
Hi,
Andres Freund <andres@anarazel.de> writes:
Both heap_expand_tuple() and minimal_expand_tuple() being unused, make
expand_tuple() unused in turn.
I think we probably ought to remove all three in 20? I didn't find external
callers. It's nontrivial enough code that I don't think we should keep it
around just because somebody might be using it.... BTW, upon looking at the code coverage report to confirm these
are unused, I noticed that the adjacent heap_copytuple_with_tuple is
also unreferenced.
Today I re-discovered this fact and recalled this discussion. Here is
the patch in case it will speed-up things.
--
Best regards,
Aleksander Alekseev
Hello PG hackers,
I saw this Commitfest patch and thought it might be a good one for me to
begin engaging with the PG community on through review. The patch removes
`expand_tuple, heap_expand_tuple, minimal_expand_tuple, and
heap_copytuple_with_tuple`.
I went ahead and checked out the PG master branch as of commit 6e70bef. I
verified the patch contents do what is expected -- removing these functions
and updating the test comments. I verified the patch applies cleanly to
6e70bef.
```
# On master
% git grep -n -w -e expand_tuple -e heap_expand_tuple -e
minimal_expand_tuple -e heap_copytuple_with_tuple master
master:src/backend/access/common/heaptuple.c:703: *
heap_copytuple_with_tuple
master:src/backend/access/common/heaptuple.c:712:heap_copytuple_with_tuple(HeapTuple
src, HeapTuple dest)
master:src/backend/access/common/heaptuple.c:738:expand_tuple(HeapTuple
*targetHeapTuple,
master:src/backend/access/common/heaptuple.c:962:minimal_expand_tuple(HeapTuple
sourceTuple, TupleDesc tupleDesc)
master:src/backend/access/common/heaptuple.c:966: expand_tuple(NULL,
&minimalTuple, sourceTuple, tupleDesc);
master:src/backend/access/common/heaptuple.c:974:heap_expand_tuple(HeapTuple
sourceTuple, TupleDesc tupleDesc)
master:src/backend/access/common/heaptuple.c:978:
expand_tuple(&heapTuple, NULL, sourceTuple, tupleDesc);
master:src/include/access/htup_details.h:809:extern void
heap_copytuple_with_tuple(HeapTuple src, HeapTuple dest);
master:src/include/access/htup_details.h:835:extern HeapTuple
heap_expand_tuple(HeapTuple sourceTuple, TupleDesc tupleDesc);
master:src/include/access/htup_details.h:836:extern MinimalTuple
minimal_expand_tuple(HeapTuple sourceTuple, TupleDesc tupleDesc);
master:src/test/regress/expected/fast_default.out:603:-- query to exercise
expand_tuple function
master:src/test/regress/expected/fast_default.out:639:-- in expand_tuple,
and that rows are correctly expanded for triggers
master:src/test/regress/sql/fast_default.sql:416:-- query to exercise
expand_tuple function
master:src/test/regress/sql/fast_default.sql:432:-- in expand_tuple, and
that rows are correctly expanded for triggers
# After the patch is applied
% git grep -n -w -e expand_tuple -e heap_expand_tuple -e
minimal_expand_tuple -e heap_copytuple_with_tuple review-7284
# Nothing found
```
Next I built Postgres in a Debian trixie-slim container (on ARM), with most
dependencies except docs and dtrace.
I ran a suite of tests with `meson test -C /build --print-errorlogs` which
passes.
```
Ok: 392
Expected Fail: 0
Fail: 0
Unexpected Pass: 0
Skipped: 36
Timeout: 0
```
All 36 skips are suites disabled by default: 35 gated behind PG_TEST_EXTRA,
which I did not set, plus one Windows-only SSPI authentication test.
I did not encounter any issues while evaluating the patch.
Best,
Kyle