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.94.2) (envelope-from ) id 1uPiYn-00ENzB-Vh for pgsql-bugs@arkaria.postgresql.org; Thu, 12 Jun 2025 14:05:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uPiYm-00DBTO-2h for pgsql-bugs@arkaria.postgresql.org; Thu, 12 Jun 2025 14:05:40 +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.94.2) (envelope-from ) id 1uPiYl-00DBRi-Q0 for pgsql-bugs@lists.postgresql.org; Thu, 12 Jun 2025 14:05:40 +0000 Received: from lana.depesz.com ([88.198.49.178] helo=depesz.com) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uPiYk-001cH6-0J for pgsql-bugs@lists.postgresql.org; Thu, 12 Jun 2025 14:05: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:Cc:To:Sender:From:Date:Content-ID: Content-Description; bh=Twj6IsgLjbWCWDRvxCQpUxrGY5H02fFhwA6vQ0rHgxE=; b=A6oAX rr6QQxnvM5h2aBeTWOEj2uJS8L0snUjpOEhgRNUEyS4PXVd/p/nvaCuw1LOklUjxVAPKq8JDmsGy+ AOE4kJZNmecLEvW4vQCpc5N+SX/outK9WPt+QCS96csbTZQG9sqgHPaiaOUqJvq2aySMaT4ICJs8Q DLiKuL6OD5Ac=; Received: from depesz by depesz.com with local (Exim 4.96) (envelope-from ) id 1uPiYg-004KL2-2a; Thu, 12 Jun 2025 16:05:34 +0200 Date: Thu, 12 Jun 2025 16:05:34 +0200 From: hubert depesz lubaczewski Sender: depesz@depesz.com To: Tom Lane Cc: anudeepvattikonda0404@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18956: Observing an issue in regexp_count() Message-ID: Reply-To: depesz@depesz.com References: <18956-9169151921910054@postgresql.org> <1203062.1749736486@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1203062.1749736486@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Jun 12, 2025 at 09:54:46AM -0400, Tom Lane wrote: > hubert depesz lubaczewski writes: > > On Thu, Jun 12, 2025 at 08:03:25AM +0000, PG Bug reporting form wrote: > >> I am trying to run the below query > >> select REGEXP_COUNT('cat at the flat', '\Bat\b') ; > >> I was expecting it to return 2 but I see Postgres is returning 0. I see that > >> there are two matches, cat and flat. All it should do is to look for the > >> word at whose left side shoudn't be a word boundary while the right side > >> should be a word boundary > > > What makes you think that \B/\b has anything to do with word boundary? > > Indeed, they do not. > > > As far as I can tell pg regexps have nothing related to word boundaries. > > Sure we do, see "Regular Expression Constraint Escapes": > > https://www.postgresql.org/docs/current/functions-matching.html#POSIX-CONSTRAINT-ESCAPES-TABLE > > Unfortunately, since these are all way outside the POSIX regexp > standard, different systems have implemented these extensions > differently. I don't doubt that \B/\b mean word boundaries > in some other system. Oh, Missed that. Thanks. So the regexp can be rewritten to: =$ select REGEXP_COUNT('cat at the flat', '\Yat\M'); regexp_count ────────────── 2 (1 row) Best regards, depesz