SQLParser: Introduce LIMIT clause

[tomschw]

New feature:

• Allow the use of LIMIT clause in SQL statements to only return the first n rows of the result frame.

Changes:

• Adjust the ANTLR parser to detect the LIMIT clause
• Apply the value of the LIMIT clause to the final sql result using the SliceRowOp in the SQL Visitor
• Introduce test case for LIMIT clause

[pdamme]

Hi @tomschw, thanks for this contribution. It's great to see that the features of the SQL parser are being extended!

Question: Was is a conscious choice to allow only integer literals in the LIMIT clause, i.e., is it intended that expressions are not allowed (like LIMIT 1+1)? I think it would be more flexible by allowing expressions.

Please fix the following points before we can merge it:

1. Providing a negative value for the limit currently results in unexpected behavior (on my system it prints rubbish data before it segfaults). Please address this problem. In case we support expressions for the limit, please keep in mind that the value may not be known at SQL parse-time. It may become known after constant propagation. But it may not even be known until runtime.
2. Please don't reimplement how an integer literal is parsed. Currently, you use stoi(), but it would be better to call the SQL parser code that parses integer literals to guarantee exactly the same behavior. (For example, think of different formats we may support at some point, like decimal, hexadecimal, etc.)

JFYI: Given an instance of FrameType, you can derive another instance with the same column types, but all other properties reset to unknown, by FrameType::withSameColumnTypes(). I simplified the code accordingly.

[tomschw]

Hi @pdamme, as discussed on Friday the following changes should mitigate your main issues:

1. As the negative value is cast to a size_t, it will lead to a huge positive number, which might explain your behaviour. I did not fix this by including any checks in the Visitor (due to your mentioned problems) but instead fixed it in the called Kernel, sliceRowOp. Due to the nature of size_t I did not include a check for a lower limit, instead just checking if the lower limit is smaller than the higher limit and that the number of rows in either the Matrix or Frame is higher than the higher limit. This might be also be helpful for other use cases of this Kernel.
2. The existing parsing is now used by simply handling the value as a literal.

Regarding the decision of not allowing expressions: We did have a quick talk yesterday and would rather only allow literals at the moment. If there is a use case in the future which would necessitate the handling of expressions, we would of course revisit our decision.