Daniel Gustafsson writes:
>> On 15 Jul 2019, at 23:18, Fabien COELHO wrote:
>> However, the documentation does not look right, field comments are not
>> aligned. Do not use tabs in the sgml file, use spaces only, otherwise the
>> display layout is left to chance.
> Of course, that was me fat-f
I quite like this suggestion, so I’ve changed the patch to do this. Removed
the doc: in the commit message to indicate that this is no longer just touching
documentation.
About v2: applies cleanly, compiles, make check and doc gen ok.
However, the documentation does not look right, field com
> On 15 Jul 2019, at 23:18, Fabien COELHO wrote:
>> I quite like this suggestion, so I’ve changed the patch to do this. Removed
>> the doc: in the commit message to indicate that this is no longer just
>> touching
>> documentation.
>
> About v2: applies cleanly, compiles, make check and doc ge
I quite like this suggestion, so I’ve changed the patch to do this. Removed
the doc: in the commit message to indicate that this is no longer just touching
documentation.
About v2: applies cleanly, compiles, make check and doc gen ok.
However, the documentation does not look right, field com
Fabien COELHO writes:
> Hello Daniel,
>> I quite like this suggestion, so I’ve changed the patch to do this.
>> Removed the doc: in the commit message to indicate that this is no
>> longer just touching documentation.
> And it should be posted to .
Seems excessive, since there's no actual func
Hello Daniel,
I quite like this suggestion, so I’ve changed the patch to do this.
Removed the doc: in the commit message to indicate that this is no
longer just touching documentation.
And it should be posted to .
--
Fabien.
> On 12 Jul 2019, at 17:04, Tom Lane wrote:
>
> Fabien COELHO writes:
>> To take into account Tom's comment, I'd suggest a middle ground by
>> commenting a public and private part explicitely in the struct, something
>> like:
Thanks for the review!
>> typedef struct {
>> /* PUBLIC memb
Hello,
To take into account Tom's comment, I'd suggest a middle ground by
commenting a public and private part explicitely in the struct,
typedef struct {
/* PUBLIC members to be used by callers ... */
/* PRIVATE members, not intended for external usage ... */
} ... ;
One pr
Fabien COELHO writes:
> To take into account Tom's comment, I'd suggest a middle ground by
> commenting a public and private part explicitely in the struct, something
> like:
>typedef struct {
> /* PUBLIC members to be used by callers ... */
> ...
> ...
> /* PRIVATE memb
Hello Daniel,
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.
Patch applies cleanly, doc build ok.
To take into account Tom's comment, I'd suggest a middle ground by
comment
On Fri, Jun 14, 2019 at 04:40:51PM +0200, Daniel Gustafsson wrote:
> 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
> On 14 Jun 2019, at 16:15, Tom Lane wrote:
>
> Daniel Gustafsson 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
Daniel Gustafsson 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
13 matches
Mail list logo
