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 1p9402-0001oi-Ab for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Dec 2022 12:51:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p9400-0002mH-U6 for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Dec 2022 12:51:36 +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 1p9400-0002m7-Cb for pgsql-hackers@lists.postgresql.org; Sat, 24 Dec 2022 12:51:36 +0000 Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p93zw-0003xB-Uk for pgsql-hackers@lists.postgresql.org; Sat, 24 Dec 2022 12:51:34 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id CB5E81C0003; Sat, 24 Dec 2022 12:51:26 +0000 (UTC) Message-ID: Date: Sat, 24 Dec 2022 07:51:25 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Error-safe user functions Content-Language: en-US To: Tom Lane Cc: Amul Sul , Andres Freund , Alexander Korotkov , Robert Haas , "David G. Johnston" , Corey Huinker , Alvaro Herrera , Joe Conway , Nikita Glukhov , PostgreSQL Hackers References: <4009543.1670422833@sss.pgh.pa.us> <20221209023351.l362yejerfoq3lfp@awork3.anarazel.de> <633426.1670554790@sss.pgh.pa.us> <01ff2051-806d-af2f-4f9e-793f7ba9a3f8@dunslane.net> <778369.1670598993@sss.pgh.pa.us> <5aaf7c66-9df9-21a9-1ff4-02c7848def52@dunslane.net> <3bac9841-fe07-713d-fa42-606c225567d6@dunslane.net> <1436686.1670701118@sss.pgh.pa.us> <2b1e7d56-6f37-bad9-9702-053ab55ecf60@dunslane.net> <1805344.1670779451@sss.pgh.pa.us> <1863335.1670783397@sss.pgh.pa.us> <2687377.1671033604@sss.pgh.pa.us> <2966981.1671057469@sss.pgh.pa.us> <1964968.1671727440@sss.pgh.pa.us> <9c8f22f2-7a37-f! c4d-8e9f-3431c0d09c5a@dunslane.net> <2769684.1671821604@sss.pgh.pa.us> From: Andrew Dunstan In-Reply-To: <2769684.1671821604@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-12-23 Fr 13:53, Tom Lane wrote: > Andrew Dunstan writes: >> On 2022-12-22 Th 11:44, Tom Lane wrote: >>> (I wonder why this is using RE_compile_and_cache at all, really, >>> rather than some other API. There doesn't seem to be value in >>> forcing the regex into the cache at this point.) >> I agree. The attached uses pg_regcomp instead. I had a lift a couple of >> lines from regexp.c, but not too many. > LGTM. No further comments. > > As I was giving this a final polish I noticed this in jspConvertRegexFlags:     /*      * We'll never need sub-match details at execution.  While      * RE_compile_and_execute would set this flag anyway, force it on here to      * ensure that the regex cache entries created by makeItemLikeRegex are      * useful.      */     cflags |= REG_NOSUB; Clearly the comment would no longer be true. I guess I should just remove this? cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com