Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rB5dU-009OAk-WD for pgsql-bugs@arkaria.postgresql.org; Thu, 07 Dec 2023 04:05:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rB5dS-00EsuU-7c for pgsql-bugs@arkaria.postgresql.org; Thu, 07 Dec 2023 04:05:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rB5dR-00EsuL-VR for pgsql-bugs@lists.postgresql.org; Thu, 07 Dec 2023 04:05:13 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rB5dL-00AUqg-7K for pgsql-bugs@lists.postgresql.org; Thu, 07 Dec 2023 04:05:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 3B7454bv1196404; Wed, 6 Dec 2023 23:05:04 -0500 From: Tom Lane To: Michael Paquier cc: Richard Guo , RekGRpth , Laurenz Albe , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18230: Redundant comparison of a local variable 'tzp' address with a NULL value at dt_common.c In-reply-to: References: <18230-c68eb05e05cb9177@postgresql.org> <51a453dfe23d1b7f33c2d9b495a4c6eb972da61e.camel@cybertec.at> Comments: In-reply-to Michael Paquier message dated "Thu, 07 Dec 2023 11:32:33 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1196402.1701921904.1@sss.pgh.pa.us> Date: Wed, 06 Dec 2023 23:05:04 -0500 Message-ID: <1196403.1701921904@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier 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