From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
cc: Daniel Gustafsson <daniel@yesql.se>, pgsql-docs@lists.postgresql.org,
        Michael Paquier <michael@paquier.xyz>
Subject: Re: SPITupleTable members missing in docs
In-reply-to: <alpine.DEB.2.21.1907121649180.8895@lancre>
References: <0D19F836-B743-4340-B6A2-F148CA3DD1F0@yesql.se>
 <alpine.DEB.2.21.1907121649180.8895@lancre>
Comments: In-reply-to Fabien COELHO <coelho@cri.ensmp.fr>
	message dated "Fri, 12 Jul 2019 16:56:31 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4583.1562943879.1@sss.pgh.pa.us>
Date: Fri, 12 Jul 2019 11:04:39 -0400
Message-ID: <4584.1562943879@sss.pgh.pa.us>
Precedence: bulk

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