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 1mNxPZ-0002LM-U0 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Sep 2021 13:14:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mNxPX-0004qg-Ao for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Sep 2021 13:14:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mNxPX-0004qX-30 for pgsql-hackers@lists.postgresql.org; Wed, 08 Sep 2021 13:14:43 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mNxPU-0006Bb-0n for pgsql-hackers@postgresql.org; Wed, 08 Sep 2021 13:14:42 +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 188DEYi03260807; Wed, 8 Sep 2021 09:14:34 -0400 From: Tom Lane To: Vik Fearing cc: Peter Eisentraut , pgsql-hackers Subject: Re: Non-decimal integer literals In-reply-to: References: Comments: In-reply-to Vik Fearing message dated "Wed, 08 Sep 2021 14:44:45 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <3260804.1631106874.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 08 Sep 2021 09:14:34 -0400 Message-ID: <3260805.1631106874@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Vik Fearing writes: > On 8/16/21 11:51 AM, Peter Eisentraut wrote: >> Here is a patch to add support for hexadecimal, octal, and binary >> integer literals: >> >>     0x42E >>     0o112 >>     0b100101 >> >> per SQL:202x draft. > Is there any hope of adding the optional underscores? I see a potential > problem there as SELECT 1_a; is currently parsed as SELECT 1 AS _a; when > it should be parsed as SELECT 1_ AS a; or perhaps even as an error since > 0x1_a would be a valid number with no alias. Even without that point, this patch *is* going to break valid queries, because every one of those cases is a valid number-followed-by-identifier today, e.g. regression=# select 0x42e; x42e ------ 0 (1 row) AFAIR we've seen exactly zero field demand for this feature, so I kind of wonder why we're in such a hurry to adopt something that hasn't even made it past draft-standard status. regards, tom lane