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 1wK3Fh-000X1G-0x for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2026 00:03:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wK3Ef-009M9g-1h for pgsql-hackers@arkaria.postgresql.org; Tue, 05 May 2026 00:02:01 +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 1wK3Ef-009M9X-0X for pgsql-hackers@lists.postgresql.org; Tue, 05 May 2026 00:02:01 +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 1wK3Eb-00000000XB9-3pwN for pgsql-hackers@postgresql.org; Tue, 05 May 2026 00:02:00 +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=zRgehKjuWb+yzfnlBczNueHe+p5v+YaoHPEiqMuTXnY=; b=F6q77zLyanFNJ1t0ElIpbmMEDD YGq1jW+ClQx1w4gI9v/q32W9Y8sG7u0zc1/8T0V7ZD4mZiZr0TJcdp3MObq72Q4biq4g5Vokhgpld 0UvAscFdSK/Lcgsn4m1/BCrDFugXODor+Iinbo3mVS+FsX0boPVZ+v0CPU57m8AtPRaZNoDquNcPU iySUd+1q7nNROiFVPtslopkCN4/J/ZujiT+u9tVdy2mg6siuFUkQTVztY5E3xHUXzmJMSYTwro5dq c6j6xWAEUrqxjXz0qutNo75dGhQyCuSWqgWI6nHw86asUqWbVsIxZ9dOYR2LP0wOXNPvszmeMcY0/ aG69xvaw==; Received: from [2409:11:4120:300:6029:524b:3eda:3d4b] (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 1wK3EO-001oGA-14; Tue, 05 May 2026 00:01:45 +0000 Date: Tue, 05 May 2026 09:01:24 +0900 (JST) Message-Id: <20260505.090124.365339750969814137.ishii@postgresql.org> To: 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 Cc: pgsql-hackers@postgresql.org Subject: Re: Row pattern recognition From: Tatsuo Ishii In-Reply-To: <20260502.140304.670813149418899420.ishii@postgresql.org> References: <20260427.174220.1939160662649810289.ishii@postgresql.org> <20260502.140304.670813149418899420.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:6029:524b:3eda:3d4b (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Attached is the v47 patches for Row pattern recognition (SQL/RPR). v47 starts to check whether range variable qualified expressions are used in DEFINE clause. If used, raise an error. This is good because we don't support the syntax yet (pattern variable range var), or it's prohibited (from clause range var). However, the error message may not be appropreate for the case when complex data type is involved. CREATE TEMP TABLE item (name TEXT, amount INT); CREATE TABLE CREATE TEMP TABLE sales(items item); CREATE TABLE SELECT (items).name, (items).amount, count(*) OVER w FROM sales WINDOW w AS ( ORDER BY (items).name ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING AFTER MATCH SKIP PAST LAST ROW PATTERN (A+) DEFINE A AS (A.items).amount > 10 ); ERROR: pattern variable qualified column reference "a.items" is not supported in DEFINE clause LINE 7: DEFINE A AS (A.items).amount > 10 ^ If I change the DEFINE clause to: DEFINE A AS (sales.items).amount > 10 I get: ERROR: range variable qualified column reference "sales.items" is not allowed in DEFINE clause LINE 8: DEFINE A AS (sales.items).amount > 10 ^ In both cases, "a.items" or "sales.items" in the error messages are not column names, therefore the wording "column reference" in the error messages are not appropriate. The checks are in transformColumnRef(). Its argument "ColumnRef *cref->fields" is a list of column ref fields in DEFINE expression in the raw parse tree. Usually it's something like range_var.col_name or just col_name etc. So it works. However when complex data types are involved, cref->fields is something like sales.items. No col_name included. In this case, ColumnRef is under Indirection node, and the col_name is stored in Indirection->indirection, not in ColumnRef. Therefore there's no way for transformColumnRef() to know the col_name. In order to fix the issue, I think we need to add code to understand range var qualification form "A.item" or "sales.items" in complex data types case. But is it worth the trouble? The reword is just nicer error messages. If we support MEASURES, the code is useful. But so far we have decided to not support it in the first cut of RPR. Maybe we should just change the error messages something like below for now? ERROR: pattern variable qualified expression "a.items" is not supported in DEFINE clause ERROR: range variable qualified expression "sales.items" is not allowed in DEFINE clause Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp