| From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
|---|---|
| To: | marko(at)joh(dot)to |
| Cc: | Karina Litskevich <litskevichkarina(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoid unused value (src/fe_utils/print.c) |
| Date: | 2023-07-11 22:46:16 |
| Message-ID: | CAEudQArH36OfEnjKpM=KWnmQaRa3XH_rGyu5ai3U_RaA9LpdEQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Em ter., 11 de jul. de 2023 às 19:34, Marko Tiikkaja <marko(at)joh(dot)to>
escreveu:
> On Thu, Jul 6, 2023 at 5:37 PM Karina Litskevich
> <litskevichkarina(at)gmail(dot)com> wrote:
> > My point is, technically right now you won't see any difference in output
> > if you remove the line. Because if we get to that line the need_recordsep
> > is already true. However, understanding why it is true is complicated.
> That's
> > why if you remove the line people who read the code will wonder why we
> don't
> > need a separator after "fputs"ing a footer. So keeping that line will
> make
> > the code more readable.
> > Moreover, removing the line will possibly complicate the future
> maintenance.
> > As I wrote in the part you just quoted, if the function changes in the
> way
> > that need_recordsep is not true right before printing footers any more,
> then
> > output will be unexpected.
>
> I agree with Karina here. Either this patch should keep the
> "need_recordsep = true;" line, thus removing the no-op assignment to
> false and making the code slightly less unreadable; or the entire
> function should be refactored for readability.
>
As there is consensus to keep the no-op assignment,
I will go ahead and reject the patch.
regards,
Ranier Vilela
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-07-11 22:49:53 | Re: Cleaning up threading code |
| Previous Message | Daniel Gustafsson | 2023-07-11 22:43:14 | Re: Reducing connection overhead in pg_upgrade compat check phase |