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
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 |