pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedSPITupleTable members missing in docs
14+ messages / 4 participants
[nested] [flat]
Commits from this thread:
2019-07-17 fec0778c80 Clarify the distinction between public and private SPITupleTable fields.
* SPITupleTable members missing in docs
@ 2019-06-14 10:55 Daniel Gustafsson <daniel@yesql.se>
0 siblings, 2 replies; 14+ messages in thread
From: Daniel Gustafsson @ 2019-06-14 10:55 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
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.
cheers ./daniel
Attachments:
spitupletable.patch (application/octet-stream, 1.9K) download
From 228df8742bfd755ee2b1b699d235270f77d64538 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <daniel@yesql.se>
Date: Fri, 14 Jun 2019 12:38:11 +0200
Subject: [PATCH] doc: Add missing members to SPITupleTable documentation
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 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 improve clarity.
---
doc/src/sgml/spi.sgml | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml
index 66eced6c94..cd6dd1c5f0 100644
--- a/doc/src/sgml/spi.sgml
+++ b/doc/src/sgml/spi.sgml
@@ -325,14 +325,16 @@ typedef struct
uint64 free; /* number of free vals */
TupleDesc tupdesc; /* row descriptor */
HeapTuple *vals; /* rows */
+ slist_node next; /* link for internal bookkeeping */
+ SubTransactionId subid; /* subxact in which tuptable was created */
} SPITupleTable;
</programlisting>
+ <structfield>vals</structfield> and <structfield>tupdesc</structfield> can
+ be used by SPI callers, the remaining fields are internal.
<structfield>vals</structfield> is an array of pointers to rows. (The number
of valid entries is given by <varname>SPI_processed</varname>.)
<structfield>tupdesc</structfield> is a row descriptor which you can pass to
- SPI functions dealing with rows. <structfield>tuptabcxt</structfield>,
- <structfield>alloced</structfield>, and <structfield>free</structfield> are internal
- fields not intended for use by SPI callers.
+ SPI functions dealing with rows.
</para>
<para>
--
2.14.1.145.gb3622a4ee
=
* Re: SPITupleTable members missing in docs
@ 2019-06-14 14:15 Tom Lane <tgl@sss.pgh.pa.us>
parent: Daniel Gustafsson <daniel@yesql.se>
1 sibling, 1 reply; 14+ messages in thread
From: Tom Lane @ 2019-06-14 14:15 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: pgsql-docs@lists.postgresql.org
Daniel Gustafsson <daniel@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.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-06-14 14:40 Daniel Gustafsson <daniel@yesql.se>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Gustafsson @ 2019-06-14 14:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org
> On 14 Jun 2019, at 16:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@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
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-06-17 02:10 Michael Paquier <michael@paquier.xyz>
parent: Daniel Gustafsson <daniel@yesql.se>
0 siblings, 0 replies; 14+ messages in thread
From: Michael Paquier @ 2019-06-17 02:10 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs@lists.postgresql.org
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.)
FWIW, we still need a proper description of these fields in the docs,
so listing them in spi.sgml has the advantage to improve the grepping
coverage of which area needs to be patched. This structure not
updated actually shows that this argument can be wrong as well ;p
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-12 14:56 Fabien COELHO <coelho@cri.ensmp.fr>
parent: Daniel Gustafsson <daniel@yesql.se>
1 sibling, 1 reply; 14+ messages in thread
From: Fabien COELHO @ 2019-07-12 14:56 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>; Tom Lane <tgl@sss.pgh.pa.us>
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
commenting a public and private part explicitely in the struct, something
like:
typedef struct {
/* PUBLIC members to be used by callers ... */
...
...
/* PRIVATE members, not intended for external usage ... */
...
} ... ;
Another option would be to use some python-like naming convention on such
members, eg with a leading underline character.
Even if it is redundant with the paragraph below, it would make things
visually clear as well.
Note: I'm probaly not a member of the pgdoc list, so the delivery may fail
there.
--
Fabien.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-12 15:04 Tom Lane <tgl@sss.pgh.pa.us>
parent: Fabien COELHO <coelho@cri.ensmp.fr>
0 siblings, 2 replies; 14+ messages in thread
From: Tom Lane @ 2019-07-12 15:04 UTC (permalink / raw)
To: Fabien COELHO <coelho@cri.ensmp.fr>; +Cc: Daniel Gustafsson <daniel@yesql.se>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
Fabien COELHO <coelho@cri.ensmp.fr> 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 members, not intended for external usage ... */
> ...
> } ... ;
One problem is that the members we've retroactively decided are "public"
are in the middle of the struct :-(.
But it occurs to me that there's no good reason we couldn't re-order the
members, as long as we only do so on HEAD and not in released versions.
That would make it a bit less inconsistent and easier to add labels
such as you suggest.
> Note: I'm probaly not a member of the pgdoc list, so the delivery may fail
> there.
FYI, I believe the current policy is that as long as you're subscribed
to at least one PG list you can post to any of them.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-12 15:59 Fabien COELHO <coelho@cri.ensmp.fr>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 14+ messages in thread
From: Fabien COELHO @ 2019-07-12 15:59 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Daniel Gustafsson <daniel@yesql.se>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
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 problem is that the members we've retroactively decided are "public"
> are in the middle of the struct :-(.
Argh, I did not notice this tiny but relevant detail.
> But it occurs to me that there's no good reason we couldn't re-order the
> members, as long as we only do so on HEAD and not in released versions.
> That would make it a bit less inconsistent and easier to add labels
> such as you suggest.
Indeed. SPI-dependent extensions are likely recompiled between major
version, so a reordering should not cause significant problems.
This mean that a simple doc patch is turned into a code patch.
--
Fabien.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-15 08:51 Daniel Gustafsson <daniel@yesql.se>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 14+ messages in thread
From: Daniel Gustafsson @ 2019-07-15 08:51 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Fabien COELHO <coelho@cri.ensmp.fr>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
> On 12 Jul 2019, at 17:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Fabien COELHO <coelho@cri.ensmp.fr> 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 members to be used by callers ... */
>> ...
>> ...
>> /* PRIVATE members, not intended for external usage ... */
>> ...
>> } ... ;
>
> One problem is that the members we've retroactively decided are "public"
> are in the middle of the struct :-(.
>
> But it occurs to me that there's no good reason we couldn't re-order the
> members, as long as we only do so on HEAD and not in released versions.
> That would make it a bit less inconsistent and easier to add labels
> such as you suggest.
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.
cheers ./daniel
Attachments:
spitupletable-v2.patch (application/octet-stream, 3.3K) download
From 9c0985edece22bd3e1c9c4f0c921dde99f14574e Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <daniel@yesql.se>
Date: Fri, 14 Jun 2019 12:38:11 +0200
Subject: [PATCH] Add missing members to SPITupleTable documentation
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 so add these too to make the
documentation match reality. Also reorder the members to separate
the public from the private fields.
Since this makes the number of internal members far outnumber the
public ones, also reword the statement about which fields can be
used to improve clarity.
fixup
---
doc/src/sgml/spi.sgml | 21 +++++++++++++--------
src/include/executor/spi.h | 7 +++++--
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml
index 66eced6c94..37fe11b4f5 100644
--- a/doc/src/sgml/spi.sgml
+++ b/doc/src/sgml/spi.sgml
@@ -320,19 +320,24 @@ SPI_execute("INSERT INTO foo SELECT * FROM bar RETURNING *", false, 5);
<programlisting>
typedef struct
{
- MemoryContext tuptabcxt; /* memory context of result table */
- uint64 alloced; /* number of alloced vals */
- uint64 free; /* number of free vals */
- TupleDesc tupdesc; /* row descriptor */
- HeapTuple *vals; /* rows */
+ /* Public members */
+ TupleDesc tupdesc; /* row descriptor */
+ HeapTuple *vals; /* rows */
+
+ /* Private members, not intended for external callers */
+ MemoryContext tuptabcxt; /* memory context of result table */
+ uint64 alloced; /* # of alloced vals */
+ uint64 free; /* # of free vals */
+ slist_node next; /* link for internal bookkeeping */
+ SubTransactionId subid; /* subxact in which tuptable was created */
} SPITupleTable;
</programlisting>
+ <structfield>vals</structfield> and <structfield>tupdesc</structfield> can
+ be used by SPI callers, the remaining fields are internal.
<structfield>vals</structfield> is an array of pointers to rows. (The number
of valid entries is given by <varname>SPI_processed</varname>.)
<structfield>tupdesc</structfield> is a row descriptor which you can pass to
- SPI functions dealing with rows. <structfield>tuptabcxt</structfield>,
- <structfield>alloced</structfield>, and <structfield>free</structfield> are internal
- fields not intended for use by SPI callers.
+ SPI functions dealing with rows.
</para>
<para>
diff --git a/src/include/executor/spi.h b/src/include/executor/spi.h
index 7bf361874d..b3dfe30f4e 100644
--- a/src/include/executor/spi.h
+++ b/src/include/executor/spi.h
@@ -21,11 +21,14 @@
typedef struct SPITupleTable
{
+ /* Public members */
+ TupleDesc tupdesc; /* tuple descriptor */
+ HeapTuple *vals; /* tuples */
+
+ /* Private members, not intended for external callers */
MemoryContext tuptabcxt; /* memory context of result table */
uint64 alloced; /* # of alloced vals */
uint64 free; /* # of free vals */
- TupleDesc tupdesc; /* tuple descriptor */
- HeapTuple *vals; /* tuples */
slist_node next; /* link for internal bookkeeping */
SubTransactionId subid; /* subxact in which tuptable was created */
} SPITupleTable;
--
2.14.1.145.gb3622a4ee
=
* Re: SPITupleTable members missing in docs
@ 2019-07-15 11:38 Fabien COELHO <coelho@cri.ensmp.fr>
parent: Daniel Gustafsson <daniel@yesql.se>
1 sibling, 1 reply; 14+ messages in thread
From: Fabien COELHO @ 2019-07-15 11:38 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
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 <pgsql-hackers@lists.postgresql.org>.
--
Fabien.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-15 13:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Fabien COELHO <coelho@cri.ensmp.fr>
0 siblings, 0 replies; 14+ messages in thread
From: Tom Lane @ 2019-07-15 13:33 UTC (permalink / raw)
To: Fabien COELHO <coelho@cri.ensmp.fr>; +Cc: Daniel Gustafsson <daniel@yesql.se>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
Fabien COELHO <coelho@cri.ensmp.fr> 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 <pgsql-hackers@lists.postgresql.org>.
Seems excessive, since there's no actual functional change here.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-15 21:18 Fabien COELHO <coelho@cri.ensmp.fr>
parent: Daniel Gustafsson <daniel@yesql.se>
1 sibling, 1 reply; 14+ messages in thread
From: Fabien COELHO @ 2019-07-15 21:18 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
> 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 comments are not
aligned. Do not use tabs in the sgml file, use spaces only, otherwise the
display layout is left to chance.
--
Fabien.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-17 11:55 Daniel Gustafsson <daniel@yesql.se>
parent: Fabien COELHO <coelho@cri.ensmp.fr>
0 siblings, 2 replies; 14+ messages in thread
From: Daniel Gustafsson @ 2019-07-17 11:55 UTC (permalink / raw)
To: Fabien COELHO <coelho@cri.ensmp.fr>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
> On 15 Jul 2019, at 23:18, Fabien COELHO <coelho@cri.ensmp.fr> 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 gen ok.
>
> 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-fingering. Fixed in the attached v3. Thanks for
reviewing!
cheers ./daniel
Attachments:
spitupletable-v3.patch (application/octet-stream, 3.3K) download
From 7644c506305336cf643101593d0b3ca7461f5469 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <daniel@yesql.se>
Date: Wed, 17 Jul 2019 13:54:02 +0200
Subject: [PATCH] Add missing members to SPITupleTable documentation
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 so add these too to make the
documentation match reality. In order to make the separation between
public and private members clearer, reorder the struct with public
and private members separate.
Since this makes the number of internal members far outnumber the
public ones, also reword the statement about which fields can be
used to improve clarity.
---
doc/src/sgml/spi.sgml | 17 +++++++++++------
src/include/executor/spi.h | 7 +++++--
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml
index 66eced6c94..cfc3ae251e 100644
--- a/doc/src/sgml/spi.sgml
+++ b/doc/src/sgml/spi.sgml
@@ -320,19 +320,24 @@ SPI_execute("INSERT INTO foo SELECT * FROM bar RETURNING *", false, 5);
<programlisting>
typedef struct
{
- MemoryContext tuptabcxt; /* memory context of result table */
- uint64 alloced; /* number of alloced vals */
- uint64 free; /* number of free vals */
+ /* Public members */
TupleDesc tupdesc; /* row descriptor */
HeapTuple *vals; /* rows */
+
+ /* Private members, not intended for external callers */
+ MemoryContext tuptabcxt; /* memory context of result table */
+ uint64 alloced; /* # of alloced vals */
+ uint64 free; /* # of free vals */
+ slist_node next; /* link for internal bookkeeping */
+ SubTransactionId subid; /* subxact in which tuptable was created */
} SPITupleTable;
</programlisting>
+ <structfield>vals</structfield> and <structfield>tupdesc</structfield> can
+ be used by SPI callers, the remaining fields are internal.
<structfield>vals</structfield> is an array of pointers to rows. (The number
of valid entries is given by <varname>SPI_processed</varname>.)
<structfield>tupdesc</structfield> is a row descriptor which you can pass to
- SPI functions dealing with rows. <structfield>tuptabcxt</structfield>,
- <structfield>alloced</structfield>, and <structfield>free</structfield> are internal
- fields not intended for use by SPI callers.
+ SPI functions dealing with rows.
</para>
<para>
diff --git a/src/include/executor/spi.h b/src/include/executor/spi.h
index 7bf361874d..b3dfe30f4e 100644
--- a/src/include/executor/spi.h
+++ b/src/include/executor/spi.h
@@ -21,11 +21,14 @@
typedef struct SPITupleTable
{
+ /* Public members */
+ TupleDesc tupdesc; /* tuple descriptor */
+ HeapTuple *vals; /* tuples */
+
+ /* Private members, not intended for external callers */
MemoryContext tuptabcxt; /* memory context of result table */
uint64 alloced; /* # of alloced vals */
uint64 free; /* # of free vals */
- TupleDesc tupdesc; /* tuple descriptor */
- HeapTuple *vals; /* tuples */
slist_node next; /* link for internal bookkeeping */
SubTransactionId subid; /* subxact in which tuptable was created */
} SPITupleTable;
--
2.14.1.145.gb3622a4ee
=
* Re: SPITupleTable members missing in docs
@ 2019-07-17 18:12 Fabien COELHO <coelho@cri.ensmp.fr>
parent: Daniel Gustafsson <daniel@yesql.se>
1 sibling, 0 replies; 14+ messages in thread
From: Fabien COELHO @ 2019-07-17 18:12 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
>>> 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 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-fingering. Fixed in the attached v3.
> Thanks for reviewing!
V3 fixes the html display alignment issue. Patch marked as ready.
--
Fabien.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: SPITupleTable members missing in docs
@ 2019-07-17 18:56 Tom Lane <tgl@sss.pgh.pa.us>
parent: Daniel Gustafsson <daniel@yesql.se>
1 sibling, 0 replies; 14+ messages in thread
From: Tom Lane @ 2019-07-17 18:56 UTC (permalink / raw)
To: Daniel Gustafsson <daniel@yesql.se>; +Cc: Fabien COELHO <coelho@cri.ensmp.fr>; pgsql-docs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
Daniel Gustafsson <daniel@yesql.se> writes:
>> On 15 Jul 2019, at 23:18, Fabien COELHO <coelho@cri.ensmp.fr> 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-fingering. Fixed in the attached v3. Thanks for
> reviewing!
Pushed with some marginal additional fiddling with the comments.
regards, tom lane
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2019-07-17 18:56 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-06-14 10:55 SPITupleTable members missing in docs Daniel Gustafsson <daniel@yesql.se>
2019-06-14 14:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-06-14 14:40 ` Daniel Gustafsson <daniel@yesql.se>
2019-06-17 02:10 ` Michael Paquier <michael@paquier.xyz>
2019-07-12 14:56 ` Fabien COELHO <coelho@cri.ensmp.fr>
2019-07-12 15:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-07-12 15:59 ` Fabien COELHO <coelho@cri.ensmp.fr>
2019-07-15 08:51 ` Daniel Gustafsson <daniel@yesql.se>
2019-07-15 11:38 ` Fabien COELHO <coelho@cri.ensmp.fr>
2019-07-15 13:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-07-15 21:18 ` Fabien COELHO <coelho@cri.ensmp.fr>
2019-07-17 11:55 ` Daniel Gustafsson <daniel@yesql.se>
2019-07-17 18:12 ` Fabien COELHO <coelho@cri.ensmp.fr>
2019-07-17 18:56 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox