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 1wYf8P-000PEE-04 for pgsql-hackers@arkaria.postgresql.org; Sun, 14 Jun 2026 07:19:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wYf8N-005xaP-2C for pgsql-hackers@arkaria.postgresql.org; Sun, 14 Jun 2026 07:19:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wYf8N-005xa7-1E for pgsql-hackers@lists.postgresql.org; Sun, 14 Jun 2026 07:19:55 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wYf8K-00000000IBV-3qG2 for pgsql-hackers@postgresql.org; Sun, 14 Jun 2026 07:19:54 +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=kWEWPjceNQ4EjkyIpD5SVZ1xaimtoW698WF+AdzePfU=; b=KWP1jN1WRG1wWoqxpge2K/FQ2z FSd6hoVBZIjhMjK7gV1n5moKGdI32pbsTYyRKhTNww97RwXcZYOkgbz6u0BNIom0dHCrlfpKmp8UO Iw1xFQP7PcY7engWkS9k6TUk4lgRa+puroVKqF79dk9IJTRKfieFFN4dEAnAC7gNZqiD6l8vUtmS7 FRp3UQck5AexoMviVo33DrVplaZCabTpIhklqfW9ZI27DRo1v7st7kA08KOY7lR7xESYaYEFZqswz v1qx3cHcp3v8MN/XrPzd3fEq6EpBhjQ4IAOVgMl0a+0U1m4D2AY5Co/xkYQ+GxFrEPzUjQZCLKO27 G1a/8RsQ==; Received: from [2409:11:4120:300:cdd8:b0b8:e63c:d97d] (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 1wYf8D-000l16-0b; Sun, 14 Jun 2026 07:19:47 +0000 Date: Sun, 14 Jun 2026 16:19:24 +0900 (JST) Message-Id: <20260614.161924.1715049956147298411.ishii@postgresql.org> To: jian.universality@gmail.com Cc: assam258@gmail.com, zsolt.parragi@percona.com, sjjang112233@gmail.com, vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com, peter@eisentraut.org, li.evan.chao@gmail.com, pgsql-hackers@postgresql.org Subject: Re: Row pattern recognition From: Tatsuo Ishii In-Reply-To: References: <20260613.212530.63949290085162247.ishii@postgresql.org> X-Mailer: Mew version 6.8 on Emacs 29.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:cdd8:b0b8:e63c:d97d (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > get_windowclause_startup_tuples > do we need some comments for WindowClause->defineClause We already have comments for DEFINE clause. Do you think it's not enough? * Moreover, if row pattern recognition is used, we charge the DEFINE * expressions once per tuple for each variable that appears in PATTERN. > src/backend/executor/README.rpr > (2) Transcription to WindowClause > - Copies rpPattern, rpSkipTo, initial fields > > In transformRPR, we did this: > ``wc->rpPattern = windef->rpCommonSyntax->rpPattern;`` > Since this is an assignment, not a copy, is "Copies rpPattern" incorrect? I think "Copies" is Ok here. Yes, we do not use copyObject to copy the rpPattern object but copying just the pointer can be regarded as kind of "copy". > ISO reference typo: most occurrences use {ISO/IEC 19075}, > but rpr_integration.sql and some places reference 9075-2:2016 instead of 19075. > We may need check all occurrences to ensure consistency. 19075 and 9075-2 are the different standard documents. 19075-5: Information technology ― Guidance for the use of database language SQL ― Part 5: Row pattern recognition 9075-2: Information technology ― Database languages ― SQL ― Part 2: Foundation (SQL/Foundation) IMO they are used differently depending on the context. > In struct ResultRelInfo, we have fields like {ri_CheckConstraintExprs, > ri_WithCheckOptionExprs}. > Similarly, I want to rename WindowAggState->defineClauseList to > defineClauseExprs Looks reasonable proposal to me. > I think the comment on function contain_rpr_walker can be removed, > since transformWithClause already explains it. I don't think we want to remove all function comments of contain_rpr_walker. However I am not against removing "Used by transformWithClause() to enforce ISO/IEC 9075-2:2016 7.17 SR 3)f) on WITH RECURSIVE elements." because it's somewhat redundant. > Is "judgment" really the right word? > > I don't fully understand the purpose of eval_nav_offset_helper now. > Also, the branch where (isnull == true) and (offset < 0) appears > unreachable; it's never hit in the regression tests. > We should add some regression tests for these scenarios. Yeah. Maybe we can turn them into Assertions? Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp