Re: Non-decimal integer literals - Mailing list pgsql-hackers

From Vik Fearing
Subject Re: Non-decimal integer literals
Date
Msg-id 8f2cdc30-350a-9782-8d95-6865a4ccb857@postgresfriends.org
Whole thread Raw
In response to Re: Non-decimal integer literals  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Non-decimal integer literals
List pgsql-hackers
On 9/8/21 3:14 PM, Tom Lane wrote:
> Vik Fearing <vik@postgresfriends.org> writes:
> 
>> 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,

Ah, true that.  So if this does go in, we may as well add the
underscores at the same time.

> AFAIR we've seen exactly zero field demand for this feature,

I have often wanted something like this, even if I didn't bring it up on
this list.  I have had customers who have wanted this, too.  My response
has always been to show these exact problems to explain why it's not
possible, but if it's going to be in the standard then I favor doing it.

I have never really had a use for octal, but sometimes binary and hex
make things much clearer.  Having a grouping separator for large numbers
is even more useful.

> 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.
I don't really see a hurry here.  I am fine with waiting until the draft
becomes final.
-- 
Vik Fearing



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: trap instead of error on 32 TiB table
Next
From: Tom Lane
Date:
Subject: Re: trap instead of error on 32 TiB table