Re: Further hacking on SPITupleTable struct - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Further hacking on SPITupleTable struct
Date
Msg-id E1AD6DAF-21CD-4B40-98AB-047338525F60@yesql.se
Whole thread Raw
In response to Further hacking on SPITupleTable struct  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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


Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
Next
From: Andrew Dunstan
Date:
Subject: Re: Compile from source using latest Microsoft Windows SDK