Re: Corrected documentation of data type for the logical replication message formats.

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Corrected documentation of data type for the logical replication message formats.
Date: 2021-08-02 15:55:55
Message-ID: CALDaNm2VFnWBgGpGOEGvNGZRxca7Mpm0HxawGa4gY6n-7UUCLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 2, 2021 at 9:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Smith <smithpb2250(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2021-08-02 15:56:01 Re: [PATCH]Comment improvement in publication.sql
Previous Message Andres Freund 2021-08-02 15:49:59 Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS