From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | Shubham Khanna <khannashubham1197(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Rajendra Kumar Dangwal <dangwalrajendra888(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, euler(at)eulerto(dot)com |
Subject: | Re: Pgoutput not capturing the generated columns |
Date: | 2024-10-29 06:28:24 |
Message-ID: | CAA4eK1Lpzy3eqd2AOM+TXp80SFL1cCfX3cf9thjL-hJxn+AYGA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 29, 2024 at 11:30 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> ======
> src/backend/replication/logical/tablesync.c
>
> fetch_remote_table_info:
>
> 2.
> +fetch_remote_table_info(char *nspname, char *relname, LogicalRepRelation *lrel,
> + List **qual, bool *remotegencolpresent)
>
> The name 'remotegencolpresent' sounds like it means a generated col is
> present in the remote table, but don't we only care when it is being
> published? So, would a better parameter name be more like
> 'remote_gencol_published'?
>
I feel no need to add a 'remote' to this variable name as the function
name itself clarifies the same. Both in the function definition and at
the caller site, we can name it 'gencol_published'.
> ~~~
>
> 3.
> Would it be better to introduce a new human-readable variable like:
> bool check_for_published_gencols = (server_version >= 180000);
>
> because then you could use that instead of having the 180000 check in
> multiple places.
>
It is better to add a comment because it makes this part of the code
difficult to enhance in the same version (18) if required.
> ~~~
>
> 4.
> - lengthof(attrRow), attrRow);
> + server_version >= 180000 ? lengthof(attrRow) : lengthof(attrRow) -
> 1, attrRow);
>
> If you wish, that length calculation could be written more concisely like:
> lengthof(attrow) - (server_version >= 180000 ? 0 : 1)
>
The current way of the patch seems easier to follow.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-10-29 06:28:51 | Re: protocol-level wait-for-LSN |
Previous Message | Bykov Ivan | 2024-10-29 06:27:25 | RE: [PoC] Partition path cache |