pgsql: Further adjust SPITupleTable to provide a public row-countfield - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Further adjust SPITupleTable to provide a public row-countfield
Date
Msg-id E1ho7X6-0006QO-FN@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Further adjust SPITupleTable to provide a public row-count field.

Now that commit fec0778c8 drew a clear line between public and private
fields in SPITupleTable, it seems pretty silly that the count of valid
tuples isn't on the public side of that line.  The reason why not was
that there wasn't such a count.  For reasons lost in the mists of time,
spi.c preferred to keep a count of remaining free entries in the array.
But that seems pretty pointless: it's unlike the way we handle similar
code everywhere else, and it involves extra subtractions that surely
outweigh having to do a comparison rather than test-for-zero to check
for array-full.

Hence, rearrange so that this code does the expansible array logic
the same as everywhere else, with a count of valid entries alongside
the allocated array length.  And document the count as public.

I looked for core-code callers where it would make sense to start
relying on tuptable->numvals rather than the separate SPI_processed
variable.  Right now there don't seem to be places where it'd be
a win to do so without more code restructuring than I care to
undertake today.  In principle, though, having SPITupleTables be
fully self-contained should be helpful down the line.

Discussion: https://postgr.es/m/16852.1563395722@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/bc8393cf27731055467a83068c680c86f9c112ea

Modified Files
--------------
doc/src/sgml/spi.sgml      | 20 ++++++++++++--------
src/backend/executor/spi.c | 22 +++++++++++-----------
src/include/executor/spi.h |  4 ++--
3 files changed, 25 insertions(+), 21 deletions(-)


pgsql-committers by date:

Previous
From: Tomas Vondra
Date:
Subject: pgsql: Fix handling of opclauses in extended statistics
Next
From: Peter Geoghegan
Date:
Subject: pgsql: Fix nbtree metapage cache upgrade bug.