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 1vqLKl-00964U-2M for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Feb 2026 01:17:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vqLKk-006WXd-37 for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Feb 2026 01:17:31 +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 1vqLKk-006WXV-1h for pgsql-hackers@lists.postgresql.org; Thu, 12 Feb 2026 01:17:31 +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 1vqLKj-00000000Eqg-0swl for pgsql-hackers@postgresql.org; Thu, 12 Feb 2026 01:17:31 +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=YFU3LZqaj6bksNB2FHg2h+72iXP32HWo2fd2G7tQXj8=; b=o0aPsfTL/2CvsopcZghzOaO9Lj qqVKY6B673o3Sv8FJIbSmMXeI7POXUtw9AqKD1lXX+PuComPzWmhliTA+vlOmnpfAf2AtfEH83BM9 09/JOaXFEAPBFEXOznhCL7AVpxGlI8aKiFuTM4F02KjCX2NhcOVzSwB6BeEOai3yectIs7kALnvSs yo1E2idA2B01xCJaSrua/gTgQETZjxp+k5Ald7Z2Tda2RColgOTZWfr+zTryyMPvHhz3VTfUWCujS 1iJH977hvWwg7A7NuSIWVmoyx+mug8kPQbBaszFmmPZJvtRINM9pt6aDHutnrSCmN4mZYmTwByg2/ NmioCA9g==; Received: from [2409:11:4120:300:261d:a50e:e439:3a8b] (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 1vqLKb-000iIO-0H; Thu, 12 Feb 2026 01:17:24 +0000 Date: Thu, 12 Feb 2026 10:17:01 +0900 (JST) Message-Id: <20260212.101701.1434868071304923886.ishii@postgresql.org> To: ssam258@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: <20260211.125032.1207789314761104094.ishii@postgresql.org> References: <20260209.190209.470246357440525054.ishii@postgresql.org> <20260211.125032.1207789314761104094.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:261d:a50e:e439:3a8b (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Henson, I found following in rpr_base.sql: -- {0} is not allowed (min must be >= 1) SELECT id, val, COUNT(*) OVER w as cnt FROM rpr_quant WINDOW w AS ( ORDER BY id ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING PATTERN (A{0} B) DEFINE A AS val > 1000, B AS val > 0 ) ORDER BY id; However in my uderstanding the SQL standard allows A{0}. PATTERN (A{0} B) is equivalant to: PATTERN (B) Another interesting PATTERN is: A{,} This is equivalant to A{0,} BTW, after studied this more, I found that A{0,0} is not allowed. In this form the right hand side number shall be greater than 0. From ISO/IEC 9075-2 7.9 "Syntax Rules 20) "If is specified, then let VUI1 and VUI2 be the values of the first and second 's, respectively. VUI1 shall be less than or equal to VUI2, and VUI2 shall be greater than 0 (zero)." However according to the Google, Oracle and Snowflake allows A{0,0}: they break the standard. So, what do you think PostgreSQL should do here? My preference is "always follow the standard". But others might think differently. Best regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp