]> granicus.if.org Git - postgresql/commit
Further adjust SPITupleTable to provide a public row-count field.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 18 Jul 2019 14:37:13 +0000 (10:37 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 18 Jul 2019 14:37:13 +0000 (10:37 -0400)
commitbc8393cf27731055467a83068c680c86f9c112ea
tree4b6a49d2e42aae6ca9d4fc4bbfd1fce4a0d40079
parent7d24f6a49076f975ca87926b3cde8fdea3448ecb
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
doc/src/sgml/spi.sgml
src/backend/executor/spi.c
src/include/executor/spi.h