> On 14 Jun 2019, at 16:15, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <dan...@yesql.se> writes:
>> Commit 3d13623d75d3206c8f009353415043a191ebab39 added the next and subid
>> fields
>> to the SPITupleTable struct, but they never made it into the documentation.
>> While these are internal members, we already document several other internal
>> ones (with a sentence on not using them) so add these too to make the
>> documentation match reality.
>
>> Since this makes the number of internal members far outnumber the public
>> ones,
>> also reword the statement about which fields can be used to try and improve
>> clarity.
>
> I wonder if we should just show the public fields in the docs? Something
> like
>
> typedef struct
> {
> ...
> TupleDesc tupdesc; /* row descriptor */
> HeapTuple *vals; /* rows */
> ...
> } SPITupleTable;
>
> (The struct contains additional fields that should not be touched
> by users of SPI.)
>
> Not wedded to that, but it would reduce the risks of future mistakes
> of this same sort.
Yeah, that’s clearly an alternative. If we go down this route, then perhaps
the docs should be swept for other instances (if any) and handle them all to
keep things consistent? (and yes, I volunteer if we want to opt for that.)
cheers ./daniel
