trailing junk in numeric literals
I was surprised to find that this doesn't error:
=> select 100a;
a
-----
100
I suspect this and similar cases used to error before aliases without AS
were introduced. But now this seems possibly problematic. Should we
try to handle this better?
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
I was surprised to find that this doesn't error:
=> select 100a;
a
-----
100
I suspect this and similar cases used to error before aliases without AS
were introduced. But now this seems possibly problematic. Should we
try to handle this better?
Meh. I think you'd get more brickbats than kudos if you start insisting
on a space there.
I'm too lazy to try to decipher the SQL spec right now, but ISTR that
it insists on whitespace between a numeric literal and an identifier.
So strictly speaking this SQL code is nonstandard anyway. But our
lexer has always been forgiving about not requiring space if it's
not logically necessary to separate tokens. I doubt trying to
change that would improve matters.
regards, tom lane
On 2020-12-28 21:54, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
I was surprised to find that this doesn't error:
=> select 100a;
a
-----
100I suspect this and similar cases used to error before aliases without AS
were introduced. But now this seems possibly problematic. Should we
try to handle this better?Meh. I think you'd get more brickbats than kudos if you start insisting
on a space there.I'm too lazy to try to decipher the SQL spec right now, but ISTR that
it insists on whitespace between a numeric literal and an identifier.
Yeah, non-delimiter tokens are supposed to be separated by delimiter tokens.
So strictly speaking this SQL code is nonstandard anyway. But our
lexer has always been forgiving about not requiring space if it's
not logically necessary to separate tokens. I doubt trying to
change that would improve matters.
Well, the idea is to diagnose potential typos better. But if there is
no interest, then that's fine.
Hello Peter,
My 0.02€:
So strictly speaking this SQL code is nonstandard anyway. But our
lexer has always been forgiving about not requiring space if it's
not logically necessary to separate tokens. I doubt trying to
change that would improve matters.Well, the idea is to diagnose potential typos better. But if there is no
interest, then that's fine.
ISTM that silently accepting bogus syntax hides bugs rather than helps
users. I'm personaly all for fixing these, especially when I'm said user.
My latest catch was:
SELECT TIMESTAMP '2020-12-29Z06:16:18'; # 2020-12-29 00:00:00
But:
SELECT TIMESTAMPTZ '2020-12-29Z06:16:18'; # 2020-12-29 07:16:18+01
SELECT TIMESTAMP '2020-12-29T06:16:18'; # 2020-12-29 06:16:18
I happen to type a O which is close to 0 for which the shift key is also
needed on the French keyboard. This makes the unhelpful:
SELECT 12O; # 12 as O
I think that the policy should be to help user by detecting mistyped
entries, not trying to interpret them out of the norm and expectations.
--
Fabien.
On 12/29/20 10:18 AM, Peter Eisentraut wrote:
On 2020-12-28 21:54, Tom Lane wrote:
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
I was surprised to find that this doesn't error:
=> select 100a;
a
-----
100I suspect this and similar cases used to error before aliases without AS
were introduced. But now this seems possibly problematic. Should we
try to handle this better?Meh. I think you'd get more brickbats than kudos if you start insisting
on a space there.I'm too lazy to try to decipher the SQL spec right now, but ISTR that
it insists on whitespace between a numeric literal and an identifier.Yeah, non-delimiter tokens are supposed to be separated by delimiter
tokens.So strictly speaking this SQL code is nonstandard anyway. But our
lexer has always been forgiving about not requiring space if it's
not logically necessary to separate tokens. I doubt trying to
change that would improve matters.Well, the idea is to diagnose potential typos better. But if there is
no interest, then that's fine.
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).
It would also allow us to have 0xdead_beef, 0o_777, and 0b1010_0000_1110
without most of it being interpreted as an alias.
--
Vik Fearing
On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).It would also allow us to have 0xdead_beef, 0o_777, and 0b1010_0000_1110
without most of it being interpreted as an alias.
That would be a nice feature. Is it part of the SQL standard?
Andreas
On 1/16/21 4:32 PM, Andreas Karlsson wrote:
On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).It would also allow us to have 0xdead_beef, 0o_777, and 0b1010_0000_1110
without most of it being interpreted as an alias.That would be a nice feature. Is it part of the SQL standard?
Yes, all of that is in the standard.
--
Vik Fearing
Vik Fearing <vik@postgresfriends.org> writes:
On 1/16/21 4:32 PM, Andreas Karlsson wrote:
On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).
It would also allow us to have 0xdead_beef, 0o_777, and 0b1010_0000_1110
without most of it being interpreted as an alias.
That would be a nice feature. Is it part of the SQL standard?
Yes, all of that is in the standard.
Really? Please cite chapter and verse. AFAICS in SQL:2011 5.3 <literal>,
a numeric literal can't contain any extraneous characters, just sign,
digits, optional decimal point, and optional exponent. Hex and octal
literals are certainly not there either.
regards, tom lane
On 1/16/21 6:10 PM, Tom Lane wrote:
Vik Fearing <vik@postgresfriends.org> writes:
On 1/16/21 4:32 PM, Andreas Karlsson wrote:
On 1/16/21 2:02 PM, Vik Fearing wrote:
I am in favor of such a change so that we can also accept 1_000_000
which currently parses as "1 AS _000_000" (which also isn't compliant
because identifiers cannot start with an underscore, but I don't want to
take it that far).
It would also allow us to have 0xdead_beef, 0o_777, and 0b1010_0000_1110
without most of it being interpreted as an alias.That would be a nice feature. Is it part of the SQL standard?
Yes, all of that is in the standard.
Really? Please cite chapter and verse. AFAICS in SQL:2011 5.3 <literal>,
a numeric literal can't contain any extraneous characters, just sign,
digits, optional decimal point, and optional exponent. Hex and octal
literals are certainly not there either.
With respect, you are looking at a 10-year-old document and I am not.
5.3 <literal> has since been modified.
--
Vik Fearing