The answer depends on where the query is run. If run from SQL Server Management Studio, you get the answer given. With the 9 columns being:
E (No name) ight Eight E8E Eight (No name) ight Eight
However, when I ran the same query in Microsoft Visual Studio's Query window I got different column names:
E E Eight Eight E8E Eight Expr1 Eight Eight
The data was the same in both cases.
Interesting point, aboyce. It looks to me as though VS parses in a more intuitive way. Where SSMS drops the letter "E" in cases where it's not interpreted as part of the numeric value (as in the second and third columns), VS retains it as part of the column name. I just tried this and see that Visual Studio first shows us a re-formatted query with explicit "AS" markers for the column aliases, wven before we hit "execute".
The original query:
Select 1.8 E,1.8E,1.Eight,3+8E8Eight,
3+8 E8E,'Six'+'Seven' 'Eight','Six'+'Seven'+'Eight',
Visual Studio reformats as:
SELECT 1.8 AS E, 1.8 AS E, 1. AS Eight, 3 + 8E8 AS Eight, 3 + 8 AS E8E, 'Six' + 'Seven' AS 'Eight', 'Six' + 'Seven' + 'Eight' AS Expr1, 8.8 AS Eight, 'Six''Seven' AS 'Eight'
When cut and pasted to SSMS, of course this reformatted query gives the same column names as the final result in VS.
The important point here would seem to be that the environment from which a query is run can affect its output. I haven't tried embedding this sort of parsing mess into a program, but wouldn't be surprised if SQL Server treated it in yet another way.