On Sun, Aug 1, 2021 at 4:11 PM Peter Smith <smithpb2...@gmail.com> wrote: > > On Sat, Jul 31, 2021 at 7:00 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > vignesh C <vignes...@gmail.com> writes: > > [ v6-0001-Included-the-actual-datatype-used-in-logical-repl.patch ] > > > > I see what you want to do here, but the way you did it seems quite > > detrimental to the readability of the field descriptions. > > Parenthesized interjections should be used sparingly. > > > > I'm inclined to think that the equivalent data type is part of the > > field data type specification, and thus that we ought to put it in > > the data type part of each entry. So we'd have something like > > > > <varlistentry> > > <term> > > Int64 (XLogRecPtr) > > </term> > > <listitem> > > <para> > > The final LSN of the transaction. > > </para> > > </listitem> > > </varlistentry> > > > > instead of what you did here. Parentheses might not be the best > > punctuation to use, given the existing convention about parenthesized > > specific values, but we could probably settle on some other markup. > > Or just ignore the ambiguity. > > +1 to change it like suggested above. > > The specific value for the flags might then look like below, but that > does not look too bad to me. > > <term> > Int8 (uint8) (0) > </term>
I felt we can change it like: <term> Int8(0) (uint8) </term> I felt the flag value can be kept first followed by the data type since it is used similarly for the other message types like below: <term> Byte1('C') </term> I have made changes in similar lines and posted the patch at [1]. Thoughts? [1] - https://www.postgresql.org/message-id/CALDaNm3sK75Mo%2BVzLmNGe29gYtJoeKHshAK0GDiAzfAj6LQPdw%40mail.gmail.com Regards, Vignesh