Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pLO42-00009t-4P for pgsql-bugs@arkaria.postgresql.org; Fri, 27 Jan 2023 12:42:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pLO40-0005lj-Nm for pgsql-bugs@arkaria.postgresql.org; Fri, 27 Jan 2023 12:42:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pLO40-0005la-70 for pgsql-bugs@lists.postgresql.org; Fri, 27 Jan 2023 12:42:40 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pLO3x-0005zR-9S for pgsql-bugs@lists.postgresql.org; Fri, 27 Jan 2023 12:42:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=depesz.com; s=20170201; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version :References:Reply-To:Message-ID:Subject:To:Sender:From:Date:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=A8McfXvUACJyp2Fl/BbP4KemIuRQCXh5XHa2QvRnSS8=; b=GGJ4nv51k39w8GGossYpsDK308 nhCsTSc0L4OfNp4boSA5tMhvXOl14O2rxDjzgwloe4/7DJcmE9NeDVZeV9IEBxXD1UU8JXayZFRoq o6A7Q+Yx5tyrSmFTdyxX/h/d2B6MCsMSI2lqdt8SESB8HgBmd/+RQyuy3LqAjwIA/+VU=; Received: from depesz by depesz.com with local (Exim 4.94.2) (envelope-from ) id 1pLO3u-00E1a4-5x; Fri, 27 Jan 2023 13:42:34 +0100 Date: Fri, 27 Jan 2023 13:42:34 +0100 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: kosiodg@yahoo.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17761: Questionable regular expression behavior Message-ID: Reply-To: depesz@depesz.com References: <17761-5a78c34533f3ab72@postgresql.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17761-5a78c34533f3ab72@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jan 27, 2023 at 09:27:35AM +0000, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 17761 > Logged by: Konstantin Geordzhev > Email address: kosiodg@yahoo.com > PostgreSQL version: 11.10 > Operating system: tested online > Description: > > Executing: > select regexp_matches('a 1x1250x2500', > '(a).*?([1-9]\d*)\s*x\s*([1-9]\d*)(?:\s*x\s*([1-9]\d*))?'); > returns: {a,1,1,NULL} > while executing: > select regexp_matches('a 1x1250x2500', > '(a|b).*?([1-9]\d*)\s*x\s*([1-9]\d*)(?:\s*x\s*([1-9]\d*))?'); > returns: {a,1,1250,2500} > > Shouldn't both results be equal? The problem is, afair, that there is some state in pg's regexp engine that makes greedy/ungreedy decision once per regexp. I don't recall details, but my take from back when I learned about it (years ago) is to try to avoid things like .*? Instead you can: #v+ $ select regexp_matches('a 1x1250x2500', '(a)\D*([1-9]\d*)\s*x\s*([1-9]\d*)(?:\s*x\s*([1-9]\d*))?'); regexp_matches ───────────────── {a,1,1250,2500} (1 row) #v- depesz