Re: Avoid unused value (src/fe_utils/print.c)

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/

In response to

Responses

Browse pgsql-hackers by date

  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