Re: Corrected documentation of data type for the logical replication message formats. - Mailing list pgsql-hackers

From vignesh C
Subject Re: Corrected documentation of data type for the logical replication message formats.
Date
Msg-id CALDaNm2VFnWBgGpGOEGvNGZRxca7Mpm0HxawGa4gY6n-7UUCLQ@mail.gmail.com
Whole thread Raw
In response to Re: Corrected documentation of data type for the logical replication message formats.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Aug 2, 2021 at 9:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Smith <smithpb2250@gmail.com> writes:
> > I agree. The specified value looks better when it comes first, as you did it.
>
> Actually, it looks to me like we don't have to resolve the question of
> which should come first, because I don't see any cases where it's
> useful to have both.  I don't agree with appending "uint8" to those
> field descriptions, because it's adding no information, especially
> when the high bit couldn't be set anyway.
>
> At some point it might be useful to add UInt<n> to the set of base
> data types, and then go through all the message types and decide
> which fields we think are unsigned.  But that is not this patch,
> and there would be questions about whether it constituted a protocol
> break.
>
> I noticed also that having to add "(Oid)" was sort of self-inflicted
> damage, because the field descriptions were using the very vague
> term "ID", when they could have said "OID" and been clear.  I left
> the "(Oid)" additions in place but also changed the text.
>
> Pushed with those changes.  I couldn't resist copy-editing the section
> intro, too.

Thanks for pushing the patch.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Next
From: vignesh C
Date:
Subject: Re: [PATCH]Comment improvement in publication.sql