Further hacking on SPITupleTable struct
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:t40945psql -h localhost -U postgresBuilt from patchset v2 (message #2), September 20, 2026 at 03:25 PM.
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 t40945_2 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 t40945_2 && git checkout t40945_2Patchset v2 (message #2) is on t40945_2
Thinking more about the public/private field distinction we just
specified --- it's always annoyed me that SPITupleTable doesn't
provide a number-of-valid-rows field, so that callers have to
look at the entirely separate SPI_processed variable in order
to make sense of SPI_tuptable. I looked a bit more closely at
the code in question, and realized that it was just Randomly
Doing Things Differently from every other implementation we have
of expansible arrays. Not only is it randomly different, but
it's not even better than our usual method of tracking current
and maximum numbers of elements: it has to do extra subtractions.
Accordingly, I propose the attached follow-on to fec0778c8,
which replaces the "free" field with a "numvals" field that
is considered public.
I poked around for callers that might prefer to use SPI_tuptable->numvals
in place of SPI_processed, and didn't immediately find anything where the
benefit of changing seemed compelling. In principle, though, it should
be possible to simplify some callers by needing only one variable to be
passed around instead of two.
Thoughts?
regards, tom lane
Attachments:
provide-public-numvals-field.patchtext/x-diff; charset=us-ascii; name=provide-public-numvals-field.patchDownload+25-21
On 17 Jul 2019, at 22:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thinking more about the public/private field distinction we just
specified --- it's always annoyed me that SPITupleTable doesn't
provide a number-of-valid-rows field, so that callers have to
look at the entirely separate SPI_processed variable in order
to make sense of SPI_tuptable.
Sorry for being slow to return to this, I see you have already committed it.
FWIW, I do agree that this makes a lot more sense. Retroactively +1’ing it.
Regarding the core code I agree that no callers directly benefit without some
refactoring, but contrib/xml2/xpath.c has one case which seems applicable as
per the attached. Now, since contrib/xml2 has been deprecated for a long time
it’s probably not worth bothering, but it was the one case I found so I figured
I’d record it in this thread.
cheers ./daniel