Oracle 10XE 10.2.0.1.0

SQL> select 1. from dual;

1.
———-
1

SQL> select*from”DUAL”;

D
-
X

SQL> select”DUMMY”from”DUAL”;

D
-
X

SQL> select/**/DUMMY/**/from/**/DUAL;

D
-
X

SQL> select 1.dummy from dual;

UMMY
———-
1.0E+000

SQL> select 1a from dual;

A
———-
1

SQL> select 1d from dual;

1D
———-
1.0E+000

SQL> select 1f from dual;

1F
———-
1.0E+000

SQL> select 1from dual;
select 1from dual
*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected

SQL> select 1ffrom dual;

1F
———-
1.0E+000

Oracle 9iEE 9.2.0.8.0

SQL> select 1. from dual;

1.
———-
1

SQL> select*from”DUAL”;

D
-
X

SQL> select”DUMMY”from”DUAL”;

D
-
X

SQL> select/**/DUMMY/**/from/**/DUAL;

D
-
X

SQL> select 1.dummy from dual;

DUMMY
———-
1

SQL> select 1a from dual;

A
———-
1

SQL> select 1d from dual;

D
———-
1

SQL> select 1f from dual;

F
———-
1

SQL> select 1from dual;

1
———-
1

SQL> select 1ffrom dual;
select 1ffrom dual
*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected

So, this seems that the behavior changed between 9i and 10, in that 10 treat the “d” and “f” as special identifiers. The final line for 9i is also interesting.

I also though maybe the “D” was special because it was the first letter in “DUMMY”, and “F” the first in “FROM”:

10:

SQL> CREATE TABLE A(A INT);

Table created.

SQL> SELECT 1D FROM A;

no rows selected

SQL> INSERT INTO A VALUES(2);

1 row created.

SQL> SELECT 1D FROM A;

1D
———-
1.0E+000

SQL> SELECT 1A FROM A;

A
———-
1

9:

SQL> CREATE TABLE A(A INT);

Table created.

SQL> SELECT 1D FROM A;

no rows selected

SQL> INSERT INTO A VALUES(2);

1 row created.

SQL> SELECT 1D FROM A;

D
———-
1

SQL> SELECT 1A FROM A;

A
———-
1

So, that’s not it.

Good analysis, I assumed it had something to do with number types but didn’t investigate further.

Btw, here’s another gem, which confirms my view that such a “relaxed” parser is no good idea at all:

SQL> select 1from dual;
SQL> select 1ffrom dual;

I was not able to find information about that.

I quickly skimmed through the standard too (the BNF notation) and didn’t see anything which would enforce use of whitespace.

So, it may be that Oracle’s just following the standard on this.. (What about the “D” and “F” notation in literal values – is that specified in ANSI too?)

Anyway, after seeing a case where a NUMBER column DUMMY is silently converted to a BINARY_DOUBLE column UMMY I think there should be a safeguard against this issue. For example parser erroring out with “ORA-xyz: ambiguous expression or literal value” or something like that…

I agree that the last test you posted in the comment is quite “interesting”.

I narrowed down the issue further, the “.” is not needed either, Oracle “recognizes” the next token when character class changes from a digit to letter.

SQL> select 1a from dual;

However the “d” and “f” letters are special (and belong to number character class in literal parser) as they indicate binary_Double and binary_Float datatypes in the literal text:

SQL> select 1d from dual;

Therefore:

SQL> create table t as select 1dummy from dual;

Table created.

SQL> desc t
Name Null? Type
------------------------------- -------- --------------
1 UMMY BINARY_DOUBLE

Yes, this is getting weird, so I will downgrade my opinion on this from “flexibility” to a “feature” which should be fixed in order to alert users who happen to do typos or use wrong syntax like this…