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 1pp9ww-0005ur-S8 for pgsql-bugs@arkaria.postgresql.org; Wed, 19 Apr 2023 15:42:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pp9wv-0005kP-Ql for pgsql-bugs@arkaria.postgresql.org; Wed, 19 Apr 2023 15:42:25 +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 1pp9wv-0005kG-IZ for pgsql-bugs@lists.postgresql.org; Wed, 19 Apr 2023 15:42:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pp9wt-000i3X-9J for pgsql-bugs@lists.postgresql.org; Wed, 19 Apr 2023 15:42:24 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 33JFgK882983096; Wed, 19 Apr 2023 11:42:20 -0400 From: Tom Lane To: Richard Guo cc: PostgreSQL mailing lists Subject: Re: Assert failure with ICU support In-reply-to: References: Comments: In-reply-to Richard Guo message dated "Wed, 19 Apr 2023 18:30:10 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2983094.1681918940.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 19 Apr 2023 11:42:20 -0400 Message-ID: <2983095.1681918940@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > I happened to run into an assert failure by chance with ICU support. > Here is the query: > SELECT '1' SIMILAR TO '\൧'; > The failure happens in lexescape(), > default: > assert(iscalpha(c)); > FAILW(REG_EESCAPE); /* unknown alphabetic escape */ > break; > Without ICU support, the same query just gives an error. Interesting. > FWIW, I googled a bit and '൧' seems to be number 1 in Malayalam. The code in lexescape() is assuming that if "c" passes iscalnum(), then either it's '0'-'9' or it passes iscalpha(). This is clearly wrong in Unicode-land, which has non-ASCII digits. I imagine you can find libc locales where this fails, not only ICU. I think the question here is what we want to do with such cases: throw a regex syntax error, or just return the character as-is? The fine manual says that if the character after '\' is alphanumeric, it's an escape, and otherwise the character is quoted literally. But how shall we interpret "alphanumeric"? I'm kind of inclined to the idea that anything that's not ASCII should be considered to be literally quoted by '\', rather than being an erroneous regex escape. Maybe I'm too English-centric. But I don't like the idea that what is a valid regex should vary depending on locale. regards, tom lane