From: | Karina Litskevich <litskevichkarina(at)gmail(dot)com> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | 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-06 15:37:16 |
Message-ID: | CACiT8iZAyf+89p=WgehHr2AeBK58O2=vFf78gDmt9Aa3V=iP0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
>
>> But
>> it's not obvious, so I also have doubts about removing this line. If
>> someday
>> print options are changed, for example to support printing footers and not
>> printing headers, or anything else changes in this function, the output
>> might
>> be unexpected with this line removed.
>
>
> That part I didn't understand.
> How are we going to make this function less readable by removing the
> complicating part.
>
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.
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-07-06 15:38:38 | Re: Problems with estimating OR conditions, IS NULL on LEFT JOINs |
Previous Message | Tristan Partin | 2023-07-06 15:29:10 | Re: pg_recvlogical prints bogus error when interrupted |