LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2021, Jan de Visser <jan@de-visser.net>
|
2022-03-13 16:09:41 -06:00
|
|
|
* Copyright (c) 2022, the SerenityOS developers.
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
|
|
|
*/
|
|
|
|
|
|
2022-03-13 16:09:41 -06:00
|
|
|
#include <AK/StringView.h>
|
2021-12-29 11:47:29 -03:00
|
|
|
#include <LibRegex/Regex.h>
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
#include <LibSQL/AST/AST.h>
|
|
|
|
|
#include <LibSQL/Database.h>
|
|
|
|
|
|
|
|
|
|
namespace SQL::AST {
|
|
|
|
|
|
2022-03-13 16:09:41 -06:00
|
|
|
static constexpr StringView s_posix_basic_metacharacters = ".^$*[]+\\";
|
2021-12-29 11:47:29 -03:00
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> NumericLiteral::evaluate(ExecutionContext&) const
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
{
|
|
|
|
|
Value ret(SQLType::Float);
|
|
|
|
|
ret = value();
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> StringLiteral::evaluate(ExecutionContext&) const
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
{
|
|
|
|
|
Value ret(SQLType::Text);
|
|
|
|
|
ret = value();
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> NullLiteral::evaluate(ExecutionContext&) const
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
{
|
|
|
|
|
return Value::null();
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> NestedExpression::evaluate(ExecutionContext& context) const
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
{
|
|
|
|
|
return expression()->evaluate(context);
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> ChainedExpression::evaluate(ExecutionContext& context) const
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
{
|
|
|
|
|
Value ret(SQLType::Tuple);
|
|
|
|
|
Vector<Value> values;
|
2022-02-10 07:46:36 -05:00
|
|
|
for (auto& expression : expressions())
|
|
|
|
|
values.append(TRY(expression.evaluate(context)));
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
ret = values;
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> BinaryOperatorExpression::evaluate(ExecutionContext& context) const
|
2021-10-21 18:10:25 -04:00
|
|
|
{
|
2022-02-10 07:46:36 -05:00
|
|
|
Value lhs_value = TRY(lhs()->evaluate(context));
|
|
|
|
|
Value rhs_value = TRY(rhs()->evaluate(context));
|
|
|
|
|
|
2021-10-21 18:10:25 -04:00
|
|
|
switch (type()) {
|
|
|
|
|
case BinaryOperator::Concatenate: {
|
2022-02-10 07:46:36 -05:00
|
|
|
if (lhs_value.type() != SQLType::Text)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()) };
|
|
|
|
|
|
2021-10-21 18:10:25 -04:00
|
|
|
AK::StringBuilder builder;
|
|
|
|
|
builder.append(lhs_value.to_string());
|
|
|
|
|
builder.append(rhs_value.to_string());
|
|
|
|
|
return Value(builder.to_string());
|
|
|
|
|
}
|
|
|
|
|
case BinaryOperator::Multiplication:
|
|
|
|
|
return lhs_value.multiply(rhs_value);
|
|
|
|
|
case BinaryOperator::Division:
|
|
|
|
|
return lhs_value.divide(rhs_value);
|
|
|
|
|
case BinaryOperator::Modulo:
|
|
|
|
|
return lhs_value.modulo(rhs_value);
|
|
|
|
|
case BinaryOperator::Plus:
|
|
|
|
|
return lhs_value.add(rhs_value);
|
|
|
|
|
case BinaryOperator::Minus:
|
|
|
|
|
return lhs_value.subtract(rhs_value);
|
|
|
|
|
case BinaryOperator::ShiftLeft:
|
|
|
|
|
return lhs_value.shift_left(rhs_value);
|
|
|
|
|
case BinaryOperator::ShiftRight:
|
|
|
|
|
return lhs_value.shift_right(rhs_value);
|
|
|
|
|
case BinaryOperator::BitwiseAnd:
|
|
|
|
|
return lhs_value.bitwise_and(rhs_value);
|
|
|
|
|
case BinaryOperator::BitwiseOr:
|
|
|
|
|
return lhs_value.bitwise_or(rhs_value);
|
|
|
|
|
case BinaryOperator::LessThan:
|
|
|
|
|
return Value(lhs_value.compare(rhs_value) < 0);
|
|
|
|
|
case BinaryOperator::LessThanEquals:
|
|
|
|
|
return Value(lhs_value.compare(rhs_value) <= 0);
|
|
|
|
|
case BinaryOperator::GreaterThan:
|
|
|
|
|
return Value(lhs_value.compare(rhs_value) > 0);
|
|
|
|
|
case BinaryOperator::GreaterThanEquals:
|
|
|
|
|
return Value(lhs_value.compare(rhs_value) >= 0);
|
|
|
|
|
case BinaryOperator::Equals:
|
|
|
|
|
return Value(lhs_value.compare(rhs_value) == 0);
|
|
|
|
|
case BinaryOperator::NotEquals:
|
|
|
|
|
return Value(lhs_value.compare(rhs_value) != 0);
|
|
|
|
|
case BinaryOperator::And: {
|
|
|
|
|
auto lhs_bool_maybe = lhs_value.to_bool();
|
|
|
|
|
auto rhs_bool_maybe = rhs_value.to_bool();
|
2022-02-10 07:46:36 -05:00
|
|
|
if (!lhs_bool_maybe.has_value() || !rhs_bool_maybe.has_value())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()) };
|
|
|
|
|
|
2021-11-05 19:05:59 -04:00
|
|
|
return Value(lhs_bool_maybe.release_value() && rhs_bool_maybe.release_value());
|
2021-10-21 18:10:25 -04:00
|
|
|
}
|
|
|
|
|
case BinaryOperator::Or: {
|
|
|
|
|
auto lhs_bool_maybe = lhs_value.to_bool();
|
|
|
|
|
auto rhs_bool_maybe = rhs_value.to_bool();
|
2022-02-10 07:46:36 -05:00
|
|
|
if (!lhs_bool_maybe.has_value() || !rhs_bool_maybe.has_value())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, BinaryOperator_name(type()) };
|
|
|
|
|
|
2021-11-05 19:05:59 -04:00
|
|
|
return Value(lhs_bool_maybe.release_value() || rhs_bool_maybe.release_value());
|
2021-10-21 18:10:25 -04:00
|
|
|
}
|
2021-10-23 10:46:33 -04:00
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
2021-10-21 18:10:25 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> UnaryOperatorExpression::evaluate(ExecutionContext& context) const
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
{
|
2022-02-10 07:46:36 -05:00
|
|
|
Value expression_value = TRY(NestedExpression::evaluate(context));
|
|
|
|
|
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
switch (type()) {
|
|
|
|
|
case UnaryOperator::Plus:
|
|
|
|
|
if (expression_value.type() == SQLType::Integer || expression_value.type() == SQLType::Float)
|
|
|
|
|
return expression_value;
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NumericOperatorTypeMismatch, UnaryOperator_name(type()) };
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
case UnaryOperator::Minus:
|
|
|
|
|
if (expression_value.type() == SQLType::Integer) {
|
|
|
|
|
expression_value = -int(expression_value);
|
|
|
|
|
return expression_value;
|
|
|
|
|
}
|
|
|
|
|
if (expression_value.type() == SQLType::Float) {
|
|
|
|
|
expression_value = -double(expression_value);
|
|
|
|
|
return expression_value;
|
|
|
|
|
}
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NumericOperatorTypeMismatch, UnaryOperator_name(type()) };
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
case UnaryOperator::Not:
|
|
|
|
|
if (expression_value.type() == SQLType::Boolean) {
|
|
|
|
|
expression_value = !bool(expression_value);
|
|
|
|
|
return expression_value;
|
|
|
|
|
}
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::BooleanOperatorTypeMismatch, UnaryOperator_name(type()) };
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
case UnaryOperator::BitwiseNot:
|
|
|
|
|
if (expression_value.type() == SQLType::Integer) {
|
|
|
|
|
expression_value = ~u32(expression_value);
|
|
|
|
|
return expression_value;
|
|
|
|
|
}
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOperatorTypeMismatch, UnaryOperator_name(type()) };
|
|
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> ColumnNameExpression::evaluate(ExecutionContext& context) const
|
2021-09-16 22:29:19 +02:00
|
|
|
{
|
2022-02-10 07:46:36 -05:00
|
|
|
if (!context.current_row)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::SyntaxError, column_name() };
|
|
|
|
|
|
2021-09-16 22:29:19 +02:00
|
|
|
auto& descriptor = *context.current_row->descriptor();
|
|
|
|
|
VERIFY(context.current_row->size() == descriptor.size());
|
2021-11-02 16:49:54 -04:00
|
|
|
Optional<size_t> index_in_row;
|
2021-09-16 22:29:19 +02:00
|
|
|
for (auto ix = 0u; ix < context.current_row->size(); ix++) {
|
|
|
|
|
auto& column_descriptor = descriptor[ix];
|
2021-11-02 16:49:54 -04:00
|
|
|
if (!table_name().is_empty() && column_descriptor.table != table_name())
|
|
|
|
|
continue;
|
|
|
|
|
if (column_descriptor.name == column_name()) {
|
2022-02-10 07:46:36 -05:00
|
|
|
if (index_in_row.has_value())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::AmbiguousColumnName, column_name() };
|
|
|
|
|
|
2021-11-02 16:49:54 -04:00
|
|
|
index_in_row = ix;
|
|
|
|
|
}
|
2021-09-16 22:29:19 +02:00
|
|
|
}
|
2021-11-02 16:49:54 -04:00
|
|
|
if (index_in_row.has_value())
|
|
|
|
|
return (*context.current_row)[index_in_row.value()];
|
2022-02-10 07:46:36 -05:00
|
|
|
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::ColumnDoesNotExist, column_name() };
|
2021-09-16 22:29:19 +02:00
|
|
|
}
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
ResultOr<Value> MatchExpression::evaluate(ExecutionContext& context) const
|
2021-12-29 11:47:29 -03:00
|
|
|
{
|
|
|
|
|
switch (type()) {
|
|
|
|
|
case MatchOperator::Like: {
|
2022-02-10 07:46:36 -05:00
|
|
|
Value lhs_value = TRY(lhs()->evaluate(context));
|
|
|
|
|
Value rhs_value = TRY(rhs()->evaluate(context));
|
|
|
|
|
|
2021-12-29 11:47:29 -03:00
|
|
|
char escape_char = '\0';
|
|
|
|
|
if (escape()) {
|
2022-02-10 07:46:36 -05:00
|
|
|
auto escape_str = TRY(escape()->evaluate(context)).to_string();
|
|
|
|
|
if (escape_str.length() != 1)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::SyntaxError, "ESCAPE should be a single character" };
|
2021-12-29 11:47:29 -03:00
|
|
|
escape_char = escape_str[0];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Compile the pattern into a simple regex.
|
|
|
|
|
// https://sqlite.org/lang_expr.html#the_like_glob_regexp_and_match_operators
|
|
|
|
|
bool escaped = false;
|
|
|
|
|
AK::StringBuilder builder;
|
|
|
|
|
builder.append('^');
|
|
|
|
|
for (auto c : rhs_value.to_string()) {
|
|
|
|
|
if (escape() && c == escape_char && !escaped) {
|
|
|
|
|
escaped = true;
|
|
|
|
|
} else if (s_posix_basic_metacharacters.contains(c)) {
|
|
|
|
|
escaped = false;
|
|
|
|
|
builder.append('\\');
|
|
|
|
|
builder.append(c);
|
|
|
|
|
} else if (c == '_' && !escaped) {
|
|
|
|
|
builder.append('.');
|
|
|
|
|
} else if (c == '%' && !escaped) {
|
|
|
|
|
builder.append(".*");
|
|
|
|
|
} else {
|
|
|
|
|
escaped = false;
|
|
|
|
|
builder.append(c);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
builder.append('$');
|
2022-02-10 07:46:36 -05:00
|
|
|
|
2021-12-29 11:47:29 -03:00
|
|
|
// FIXME: We should probably cache this regex.
|
|
|
|
|
auto regex = Regex<PosixBasic>(builder.build());
|
|
|
|
|
auto result = regex.match(lhs_value.to_string(), PosixFlags::Insensitive | PosixFlags::Unicode);
|
|
|
|
|
return Value(invert_expression() ? !result.success : result.success);
|
|
|
|
|
}
|
2022-01-22 15:43:30 +01:00
|
|
|
case MatchOperator::Regexp: {
|
2022-02-10 07:46:36 -05:00
|
|
|
Value lhs_value = TRY(lhs()->evaluate(context));
|
|
|
|
|
Value rhs_value = TRY(rhs()->evaluate(context));
|
2022-01-22 15:43:30 +01:00
|
|
|
|
|
|
|
|
auto regex = Regex<PosixExtended>(rhs_value.to_string());
|
|
|
|
|
auto err = regex.parser_result.error;
|
|
|
|
|
if (err != regex::Error::NoError) {
|
|
|
|
|
StringBuilder builder;
|
|
|
|
|
builder.append("Regular expression: ");
|
|
|
|
|
builder.append(get_error_string(err));
|
|
|
|
|
|
2022-02-10 07:46:36 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::SyntaxError, builder.build() };
|
2022-01-22 15:43:30 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
auto result = regex.match(lhs_value.to_string(), PosixFlags::Insensitive | PosixFlags::Unicode);
|
|
|
|
|
return Value(invert_expression() ? !result.success : result.success);
|
|
|
|
|
}
|
2021-12-29 11:47:29 -03:00
|
|
|
case MatchOperator::Glob:
|
2022-02-10 08:15:18 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NotYetImplemented, "GLOB expression is not yet implemented"sv };
|
2021-12-29 11:47:29 -03:00
|
|
|
case MatchOperator::Match:
|
2022-02-10 08:15:18 -05:00
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::NotYetImplemented, "MATCH expression is not yet implemented"sv };
|
2021-12-29 11:47:29 -03:00
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL+SQLServer: Bare bones INSERT and SELECT statements
This patch provides very basic, bare bones implementations of the
INSERT and SELECT statements. They are *very* limited:
- The only variant of the INSERT statement that currently works is
SELECT INTO schema.table (column1, column2, ....) VALUES
(value11, value21, ...), (value12, value22, ...), ...
where the values are literals.
- The SELECT statement is even more limited, and is only provided to
allow verification of the INSERT statement. The only form implemented
is: SELECT * FROM schema.table
These statements required a bit of change in the Statement::execute
API. Originally execute only received a Database object as parameter.
This is not enough; we now pass an ExecutionContext object which
contains the Database, the current result set, and the last Tuple read
from the database. This object will undoubtedly evolve over time.
This API change dragged SQLServer::SQLStatement into the patch.
Another API addition is Expression::evaluate. This method is,
unsurprisingly, used to evaluate expressions, like the values in the
INSERT statement.
Finally, a new test file is added: TestSqlStatementExecution, which
tests the currently implemented statements. As the number and flavour of
implemented statements grows, this test file will probably have to be
restructured.
2021-07-19 19:48:46 -04:00
|
|
|
}
|