Re: BUG #18230: Redundant comparison of a local variable 'tzp' address with a NULL value at dt_common.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, RekGRpth <rekgrpth(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18230: Redundant comparison of a local variable 'tzp' address with a NULL value at dt_common.c
Date: 2023-12-07 04:05:04
Message-ID: 1196403.1701921904@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> *tzp could be given to DecodeTimezone() and manipulated inside it, but
> you are right that we don't use it at all in the DecodeDateTime()
> path. Other callers of DecodeTimezone() may depend on the changes
> done inside it, though. Perhaps DecodeTimezone() should be extended
> so as it can accept a NULL value and use that in DecodeDateTime(),
> eliminating the need for *tzp entirely?

TBH, I think our best path here is to leave well enough alone.
The main impact of the proposed changes is to make ecpg's copy
of the datetime parsing code diverge even further from the
backend's copy. I don't think that these changes buy anything
meaningful, and what they will do is make it harder to reunify
that logic, which somebody will probably try to do someday.

(The recent changes to support non-error-throwing returns from
input functions probably made that task notably easier, BTW.)

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-12-07 09:16:00 BUG #18231: String conversion function is adding special characters in Postgres 15
Previous Message Andrei Lepikhov 2023-12-07 02:55:08 Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN