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 1slyrU-002N0l-Lp for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Sep 2024 22:52:28 +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 1slyrR-00GRyf-UY for pgsql-hackers@arkaria.postgresql.org; Wed, 04 Sep 2024 22:52:26 +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 1slyrR-00GRyX-Kc for pgsql-hackers@lists.postgresql.org; Wed, 04 Sep 2024 22:52:26 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1slyrP-000BNU-Bx for pgsql-hackers@lists.postgresql.org; Wed, 04 Sep 2024 22:52: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 484MqLeH1709058; Wed, 4 Sep 2024 18:52:21 -0400 From: Tom Lane To: Karina Litskevich cc: Pavel Borisov , Postgres hackers Subject: Re: Invalid "trailing junk" error message when non-English letters are used In-reply-to: References: Comments: In-reply-to Karina Litskevich message dated "Wed, 28 Aug 2024 13:00:33 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1709056.1725490341.1@sss.pgh.pa.us> Date: Wed, 04 Sep 2024 18:52:21 -0400 Message-ID: <1709057.1725490341@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Karina Litskevich writes: > I see the two solutions here: either move the rule for decinteger_junk > below the rules for hexinteger_junk, octinteger_junk and bininteger_junk, > or just use a single rule decinteger_junk for all these cases, since the > error message is the same anyway. I implemented the latter in the second > version of the patch, also renamed this common rule to integer_junk. That seems reasonable, but IMO this code was unacceptably undercommented before and what you've done has made it worse. We really need a comment block associated with the flex macros, perhaps along the lines of /* * An identifier immediately following a numeric literal is disallowed * because in some cases it's ambiguous what is meant: for example, * 0x1234 could be either a hexinteger or a decinteger "0" and an * identifier "x1234". We can detect such problems by seeing if * integer_junk matches a longer substring than any of the XXXinteger * patterns. (One "junk" pattern is sufficient because this will match * all the same strings we'd match with {hexinteger}{identifier} etc.) * Note that the rule for integer_junk must appear after the ones for * XXXinteger to make this work correctly. */ (Hmm, actually, is that last sentence true? My flex is a bit rusty.) param_junk really needs a similar comment, or maybe we could put all the XXX_junk macros together and use one comment for all. > Additionally, I noticed that this patch is going to change error messages > in some cases, though I don't think it's a big deal. Example: > Without patch: > postgres=# select 0xyz; > ERROR: invalid hexadecimal integer at or near "0x" > With patch: > postgres=# select 0xyz; > ERROR: trailing junk after numeric literal at or near "0xyz" That's sort of annoying, but I don't really see a better way, or at least not one that's worth the effort. >> FWIW output of the whole string in the error message doesnt' look nice to >> me, but other places of code do this anyway e.g: >> select ('1'||repeat('p',1000000))::integer; >> This may be worth fixing. I think this is nonsense: we are already in the habit of repeating the whole failing query string in the STATEMENT field. In any case it's not something for this patch to worry about. regards, tom lane