| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Further hacking on SPITupleTable struct |
| Date: | 2019-07-19 12:11:02 |
| Message-ID: | E1AD6DAF-21CD-4B40-98AB-047338525F60@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 17 Jul 2019, at 22:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 | Content-Type | Size |
|---|---|---|
| xpath_numvals.diff | application/octet-stream | 810 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2019-07-19 12:30:38 | Re: Compile from source using latest Microsoft Windows SDK |
| Previous Message | Tomas Vondra | 2019-07-19 12:02:13 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |