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 1vAHRt-00Ge5U-18 for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Oct 2025 00:39:00 +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 1vAHRr-009bxD-MT for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Oct 2025 00:38:58 +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 1vAHRr-009bx2-4d for pgsql-hackers@lists.postgresql.org; Sun, 19 Oct 2025 00:38:58 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vAHRn-002yUs-2V for pgsql-hackers@lists.postgresql.org; Sun, 19 Oct 2025 00:38:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=SjKkG24pW0XvDL4GACsvPbKt9MH9wu0KFAJiEHP//+0=; b=nYvICXmd4GUtnLgNmpjqcIYK5x Qj4tYUBs9isrTWceg8eBcVLJohnxKl7tEWLFXkJGtSwThrNFjfkhDXo2pf+2cSIHFdOiyx7Sx86ZS /34EzvZ7Wf4ZuVUC1Nb3Inmq6dT1xT9IA75Q+iYv50ocs33ngb2Bt8guA0aTYhcjXPt0pyjgGrgd3 5MKNZzeDCRa5Web0RQ8Wx9EHxbhih/aB0X2jY1cS05/BVIdAxfoONZtqG750YNbdVnUga3dz246cN FQs7zHF7J2fcHa7RiGTEppReW3ZYwwcfsdL7qys1S05QS9yEPPN2wqdqAGwb7q4bE0IzbVsZTquVY NVJBCPGg==; Received: from [2409:11:4120:300:16cb:fba0:c571:6d54] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vAHRf-007LLl-2n; Sun, 19 Oct 2025 00:38:50 +0000 Date: Sun, 19 Oct 2025 09:38:31 +0900 (JST) Message-Id: <20251019.093831.1684444745027170849.ishii@postgresql.org> To: michael@paquier.xyz Cc: li.evan.chao@gmail.com, tgl@sss.pgh.pa.us, pramsey@cleverelephant.ca, ojford@gmail.com, peter@eisentraut.org, krasiyan@gmail.com, vik@postgresfriends.org, andrew@tao11.riddles.org.uk, david@fetter.org, pgsql-hackers@lists.postgresql.org Subject: Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options From: Tatsuo Ishii In-Reply-To: <20251016.191706.731898842046838424.ishii@postgresql.org> References: <20251014.192113.1554227757626092006.ishii@postgresql.org> <20251016.191706.731898842046838424.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 29.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:16cb:fba0:c571:6d54 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Thanks for the report. > >> Coverity thinks that this code has still some incorrect bits, and I >> think that it is right to think so even on today's HEAD at >> 02c171f63fca. >> >> In WinGetFuncArgInPartition()@nodeWindowAgg.c, we have the following >> loop (keeping only the relevant parts: >> do >> { >> [...] >> else /* need to check NULL or not */ >> { >> /* get tuple and evaluate in partition */ >> datum = gettuple_eval_partition(winobj, argno, >> abs_pos, isnull, &myisout); >> if (myisout) /* out of partition? */ >> break; >> if (!*isnull) >> notnull_offset++; >> /* record the row status */ >> put_notnull_info(winobj, abs_pos, *isnull); >> } >> } while (notnull_offset < notnull_relpos); >> >> /* get tuple and evaluate in partition */ >> datum = gettuple_eval_partition(winobj, argno, >> abs_pos, isnull, &myisout); >> >> And Coverity is telling that there is no point in setting a datum in >> this else condition to just override its value when we exit the while >> loop. To me, it's a sigh that this code's logic could be simplified. > > To fix the issue, I think we can change: > >> datum = gettuple_eval_partition(winobj, argno, >> abs_pos, isnull, &myisout); > > to: > > (void) gettuple_eval_partition(winobj, argno, > abs_pos, isnull, &myisout); > > This explicitely stats that we ignore the return value from > gettuple_eval_partition. I hope coverity understands this. > >> In passing, gettuple_eval_partition() is under-documented for me. Its >> name refers to the fact that it gets a tuple and evaluates a >> partition. Its top comment tells the same thing as the name of the >> function, so it's a bit hard to say why it is useful with the code >> written this way, and how others many benefit when attempting to reuse >> it, or if it even makes sense to reuse it for other purposes. > > What about changing the comment this way? > > /* gettuple_eval_partition > * get tuple in a patition and evaluate the window function's argument > * expression on it. > */ > > Attached is the patch for above. Patch pushed with minor comment tweaks. Thanks. -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp