parser: broken select statements

[Shivam010]

Describe the bug
I see some similar bugs in https://github.com/xqueries/xdb/blob/master/internal/parser/parser_test.go

xdb/internal/parser/parser_test.go

Line 4568 in 67baa13

"CREATE TABLE myTable AS SELECT *",

xdb/internal/parser/parser_test.go

Line 6596 in 67baa13

"INSERT INTO myTable SELECT *",

I am not sure whether they are intentional or indeed are missed somehow, but I think these statements and others like these should give an error related to an invalid SELECT statement or missing table name.
Even, the select query without any FROM clause and Literal, is passing.

To Reproduce
Run the tests.
Also, try SELECT *, which I think should fail.

Similar issue
Missing table name in Create statement #29

[tsatke]

SELECT * is a valid grammar production, and should fail after compilation at execution time, so these are valid parser tests. The parser should not fail attempting to parse them.

https://www.sqlite.org/lang_select.html

So in summary:
your two examples should be

• parseable
• compilable
• not executable
  If they are executable, this is an engine problem, otherwise, I would close this, as the behavior is intended.

[SUMUKHA-PK]

Whats the status on this?
Does #52 fix this? @Shivam010

[Shivam010]

As the query is parsable, the parser works fine in this case.
But I had run tests to execute the query and it seems it is executing perfectly. I have certain other examples, that are wrongly executing, like:

• select *
• select 1 from myTable

I am working on them with the possible solution.

[tsatke]

How did you execute them? What result does select * produce?
select 1 from myTable should just produce

column1 (Integer)
1

at least that's what I would expect at this point

[Shivam010]

select * returns

column1 (String)
*

whereas select 1 from myTable returns with error: no column with name 1

[Shivam010]

even select 'str' from myTable returns the same error.
It is due to the fact that they are List type commands and the expected behaviour is written in Value type command.
We have to handle the behaviour for numerical values and quoted strings to be treated as constants and not columns in List

[tsatke]

select * even makes sense... * is just considered a literal, since there is no column it matches, which is the same behavior as for select 1 or select '1'. I would leave it like that.
select 1 from myTable on the other hand should just work as select 1, given there is no such column.

Closing this in favor of #54

[tsatke]

We have to handle the behaviour for numerical values and quoted strings to be treated as constants and not columns in List

#55