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.96) (envelope-from ) id 1vukgD-004erF-0Z for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Feb 2026 05:09:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vukgA-00H6CC-20 for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Feb 2026 05:09:50 +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.96) (envelope-from ) id 1vukgA-00H6C3-0T for pgsql-hackers@lists.postgresql.org; Tue, 24 Feb 2026 05:09:50 +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.98.2) (envelope-from ) id 1vukg6-00000000yrU-3Abq for pgsql-hackers@postgresql.org; Tue, 24 Feb 2026 05:09:49 +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=luWqUFeXOdusC8vmA0n4f592H6D8/YCljbQMcSnbCVk=; b=tcWBgkCj/kkDXsJGE9E4TrgUOP X23DfrruSkOeE/bjADkHiXBYe00HC8ajtmvjWhH9Ddua3Q4QR3NQK+7qobsJDUAGO31Y2/QUz+k4L hoao4XkSfxhp1dAtxyCohH96N26z1/EslSvlMFD1uNO08tdLKVb2sw8ZY2cptZal78M2EfJuuWSsK lZWFs7xNKbd+48oZpqZsKbK2lD9ShfV6W/pJXGSGcIQofKPo/BdmXwhlWJ/O1KqHywJ4C3iet1nd8 35Q8eaipu1aVNBbeA+u2a7YhzLoubOcNNIKooexCOFJFtuphLAJIinzeM8jxpsI/8eYPuWkFPoG6Z 2T3MEaIQ==; Received: from [2409:11:4120:300:e34c:3bd3:1454:b1b6] (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 1vukfz-002BeK-2U; Tue, 24 Feb 2026 05:09:42 +0000 Date: Tue, 24 Feb 2026 14:09:27 +0900 (JST) Message-Id: <20260224.140927.1828965853586507533.ishii@postgresql.org> To: assam258@gmail.com Cc: vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com, peter@eisentraut.org, pgsql-hackers@postgresql.org Subject: Re: Row pattern recognition From: Tatsuo Ishii In-Reply-To: References: <20260224.115625.1966558814200895991.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:e34c:3bd3:1454:b1b6 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Henson, >> BTW, in create_windowagg_plan (createplan.c), >> around: >> /* Build RPR pattern and filter defineClause */ >> >> collectPatternVariables, filterDefineClause and buildRPRPattern are >> called in a block without any if or any other conditional >> statements. This is an unusual codiing style in PostgreSQL. I suggest >> to fix this. Attached is a proposed patch for this. > > Good catch, thank you! I've renumbered your patch as nocfbot-0007 > and extended the same cleanup to rpr.c and parse_rpr.c as > nocfbot-0008. > > nocfbot-0007: Refactor create_windowagg_plan to remove bare > variable-scoping block (your patch, renumbered) > > nocfbot-0008: Remove bare variable-scoping blocks in RPR code > > Applies the same cleanup to rpr.c and parse_rpr.c, with minor > pgindent formatting fixes. > > I'll keep this coding style point in mind for future code as well. Thank you for quick response! Best regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp