2021-06-17 13:23:52 -04:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2021, Jan de Visser <jan@de-visser.net>
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
* Copyright (c) 2022, Tim Flynn <trflynn89@serenityos.org>
|
2021-06-17 13:23:52 -04:00
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
|
|
|
*/
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
#include <AK/NumericLimits.h>
|
2022-12-01 22:29:17 -05:00
|
|
|
#include <LibIPC/Decoder.h>
|
|
|
|
|
#include <LibIPC/Encoder.h>
|
2022-02-11 10:23:20 -05:00
|
|
|
#include <LibSQL/AST/AST.h>
|
2021-08-18 20:50:13 -04:00
|
|
|
#include <LibSQL/Serializer.h>
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
#include <LibSQL/TupleDescriptor.h>
|
2021-06-17 13:23:52 -04:00
|
|
|
#include <LibSQL/Value.h>
|
2021-07-17 07:02:28 -04:00
|
|
|
#include <string.h>
|
2021-06-17 13:23:52 -04:00
|
|
|
|
|
|
|
|
namespace SQL {
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
// We use the upper 4 bits of the encoded type to store extra information about the type. This
|
|
|
|
|
// includes if the value is null, and the encoded size of any integer type. Of course, this encoding
|
|
|
|
|
// only works if the SQL type itself fits in the lower 4 bits.
|
|
|
|
|
enum class SQLTypeWithCount {
|
|
|
|
|
#undef __ENUMERATE_SQL_TYPE
|
|
|
|
|
#define __ENUMERATE_SQL_TYPE(name, type) type,
|
|
|
|
|
ENUMERATE_SQL_TYPES(__ENUMERATE_SQL_TYPE)
|
|
|
|
|
#undef __ENUMERATE_SQL_TYPE
|
|
|
|
|
Count,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static_assert(to_underlying(SQLTypeWithCount::Count) <= 0x0f, "Too many SQL types for current encoding");
|
|
|
|
|
|
|
|
|
|
// Adding to this list is fine, but changing the order of any value here will result in LibSQL
|
|
|
|
|
// becoming unable to read existing .db files. If the order must absolutely be changed, be sure
|
|
|
|
|
// to bump Heap::current_version.
|
|
|
|
|
enum class TypeData : u8 {
|
|
|
|
|
Null = 1 << 4,
|
|
|
|
|
Int8 = 2 << 4,
|
|
|
|
|
Int16 = 3 << 4,
|
|
|
|
|
Int32 = 4 << 4,
|
|
|
|
|
Int64 = 5 << 4,
|
|
|
|
|
Uint8 = 6 << 4,
|
|
|
|
|
Uint16 = 7 << 4,
|
|
|
|
|
Uint32 = 8 << 4,
|
|
|
|
|
Uint64 = 9 << 4,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
template<typename Callback>
|
|
|
|
|
static decltype(auto) downsize_integer(Integer auto value, Callback&& callback)
|
|
|
|
|
{
|
|
|
|
|
if constexpr (IsSigned<decltype(value)>) {
|
|
|
|
|
if (AK::is_within_range<i8>(value))
|
|
|
|
|
return callback(static_cast<i8>(value), TypeData::Int8);
|
|
|
|
|
if (AK::is_within_range<i16>(value))
|
|
|
|
|
return callback(static_cast<i16>(value), TypeData::Int16);
|
|
|
|
|
if (AK::is_within_range<i32>(value))
|
|
|
|
|
return callback(static_cast<i32>(value), TypeData::Int32);
|
|
|
|
|
return callback(value, TypeData::Int64);
|
|
|
|
|
} else {
|
|
|
|
|
if (AK::is_within_range<u8>(value))
|
|
|
|
|
return callback(static_cast<i8>(value), TypeData::Uint8);
|
|
|
|
|
if (AK::is_within_range<u16>(value))
|
|
|
|
|
return callback(static_cast<i16>(value), TypeData::Uint16);
|
|
|
|
|
if (AK::is_within_range<u32>(value))
|
|
|
|
|
return callback(static_cast<i32>(value), TypeData::Uint32);
|
|
|
|
|
return callback(value, TypeData::Uint64);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template<typename Callback>
|
|
|
|
|
static decltype(auto) downsize_integer(Value const& value, Callback&& callback)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
VERIFY(value.is_int());
|
|
|
|
|
|
|
|
|
|
if (value.value().has<i64>())
|
|
|
|
|
return downsize_integer(value.value().get<i64>(), forward<Callback>(callback));
|
|
|
|
|
return downsize_integer(value.value().get<u64>(), forward<Callback>(callback));
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
template<typename Callback>
|
|
|
|
|
static ResultOr<Value> perform_integer_operation(Value const& lhs, Value const& rhs, Callback&& callback)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
VERIFY(lhs.is_int());
|
|
|
|
|
VERIFY(rhs.is_int());
|
|
|
|
|
|
|
|
|
|
if (lhs.value().has<i64>()) {
|
|
|
|
|
if (auto rhs_value = rhs.to_int<i64>(); rhs_value.has_value())
|
|
|
|
|
return callback(lhs.to_int<i64>().value(), rhs_value.value());
|
|
|
|
|
} else {
|
|
|
|
|
if (auto rhs_value = rhs.to_int<u64>(); rhs_value.has_value())
|
|
|
|
|
return callback(lhs.to_int<u64>().value(), rhs_value.value());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
Value::Value(SQLType type)
|
|
|
|
|
: m_type(type)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
Value::Value(DeprecatedString value)
|
|
|
|
|
: m_type(SQLType::Text)
|
|
|
|
|
, m_value(move(value))
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(double value)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (trunc(value) == value) {
|
|
|
|
|
if (AK::is_within_range<i64>(value)) {
|
|
|
|
|
m_type = SQLType::Integer;
|
|
|
|
|
m_value = static_cast<i64>(value);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (AK::is_within_range<u64>(value)) {
|
|
|
|
|
m_type = SQLType::Integer;
|
|
|
|
|
m_value = static_cast<u64>(value);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m_type = SQLType::Float;
|
|
|
|
|
m_value = value;
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(NonnullRefPtr<TupleDescriptor> descriptor, Vector<Value> values)
|
|
|
|
|
: m_type(SQLType::Tuple)
|
|
|
|
|
, m_value(TupleValue { move(descriptor), move(values) })
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(Value const& other)
|
|
|
|
|
: m_type(other.m_type)
|
|
|
|
|
, m_value(other.m_value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::Value(Value&& other)
|
|
|
|
|
: m_type(other.m_type)
|
|
|
|
|
, m_value(move(other.m_value))
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value::~Value() = default;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<Value> Value::create_tuple(NonnullRefPtr<TupleDescriptor> descriptor)
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Vector<Value> values;
|
|
|
|
|
TRY(values.try_resize(descriptor->size()));
|
2021-10-21 18:06:24 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (size_t i = 0; i < descriptor->size(); ++i)
|
|
|
|
|
values[i].m_type = descriptor->at(i).type;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return Value { move(descriptor), move(values) };
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<Value> Value::create_tuple(Vector<Value> values)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto descriptor = TRY(infer_tuple_descriptor(values));
|
|
|
|
|
return Value { move(descriptor), move(values) };
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
SQLType Value::type() const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return m_type;
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
StringView Value::type_name() const
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
switch (type()) {
|
|
|
|
|
#undef __ENUMERATE_SQL_TYPE
|
2022-12-11 17:15:45 -05:00
|
|
|
#define __ENUMERATE_SQL_TYPE(name, type) \
|
|
|
|
|
case SQLType::type: \
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return name##sv;
|
|
|
|
|
ENUMERATE_SQL_TYPES(__ENUMERATE_SQL_TYPE)
|
|
|
|
|
#undef __ENUMERATE_SQL_TYPE
|
|
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
}
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
2022-12-05 07:55:21 -05:00
|
|
|
bool Value::is_type_compatible_with(SQLType other_type) const
|
|
|
|
|
{
|
|
|
|
|
switch (type()) {
|
|
|
|
|
case SQLType::Null:
|
|
|
|
|
return false;
|
|
|
|
|
case SQLType::Integer:
|
|
|
|
|
case SQLType::Float:
|
|
|
|
|
return other_type == SQLType::Integer || other_type == SQLType::Float;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return type() == other_type;
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
bool Value::is_null() const
|
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return !m_value.has_value();
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
bool Value::is_int() const
|
|
|
|
|
{
|
|
|
|
|
return m_value.has_value() && (m_value->has<i64>() || m_value->has<u64>());
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-06 01:12:49 +00:00
|
|
|
DeprecatedString Value::to_deprecated_string() const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null())
|
|
|
|
|
return "(null)"sv;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> DeprecatedString { return value; },
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
[](Integer auto value) -> DeprecatedString { return DeprecatedString::number(value); },
|
2022-12-04 18:02:33 +00:00
|
|
|
[](double value) -> DeprecatedString { return DeprecatedString::number(value); },
|
|
|
|
|
[](bool value) -> DeprecatedString { return value ? "true"sv : "false"sv; },
|
|
|
|
|
[](TupleValue const& value) -> DeprecatedString {
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
StringBuilder builder;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
builder.append('(');
|
|
|
|
|
builder.join(',', value.values);
|
|
|
|
|
builder.append(')');
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return builder.build();
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<double> Value::to_double() const
|
|
|
|
|
{
|
|
|
|
|
if (is_null())
|
|
|
|
|
return {};
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
|
return m_value->visit(
|
2022-12-14 09:59:54 -05:00
|
|
|
[](DeprecatedString const& value) -> Optional<double> { return value.to_double(); },
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
[](Integer auto value) -> Optional<double> { return static_cast<double>(value); },
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[](double value) -> Optional<double> { return value; },
|
|
|
|
|
[](bool value) -> Optional<double> { return static_cast<double>(value); },
|
|
|
|
|
[](TupleValue const&) -> Optional<double> { return {}; });
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<bool> Value::to_bool() const
|
|
|
|
|
{
|
|
|
|
|
if (is_null())
|
|
|
|
|
return {};
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> Optional<bool> {
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (value.equals_ignoring_case("true"sv) || value.equals_ignoring_case("t"sv))
|
|
|
|
|
return true;
|
|
|
|
|
if (value.equals_ignoring_case("false"sv) || value.equals_ignoring_case("f"sv))
|
|
|
|
|
return false;
|
|
|
|
|
return {};
|
|
|
|
|
},
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
[](Integer auto value) -> Optional<bool> { return static_cast<bool>(value); },
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[](double value) -> Optional<bool> { return fabs(value) > NumericLimits<double>::epsilon(); },
|
|
|
|
|
[](bool value) -> Optional<bool> { return value; },
|
|
|
|
|
[](TupleValue const& value) -> Optional<bool> {
|
|
|
|
|
for (auto const& element : value.values) {
|
|
|
|
|
auto as_bool = element.to_bool();
|
|
|
|
|
if (!as_bool.has_value())
|
|
|
|
|
return {};
|
|
|
|
|
if (!as_bool.value())
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Optional<Vector<Value>> Value::to_vector() const
|
|
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null() || (type() != SQLType::Tuple))
|
2021-07-17 07:02:28 -04:00
|
|
|
return {};
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto const& tuple = m_value->get<TupleValue>();
|
|
|
|
|
return tuple.values;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value& Value::operator=(Value value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = value.m_type;
|
|
|
|
|
m_value = move(value.m_value);
|
|
|
|
|
return *this;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
2022-12-04 18:02:33 +00:00
|
|
|
Value& Value::operator=(DeprecatedString value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Text;
|
|
|
|
|
m_value = move(value);
|
|
|
|
|
return *this;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Value& Value::operator=(double value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Float;
|
|
|
|
|
m_value = value;
|
|
|
|
|
return *this;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<void> Value::assign_tuple(NonnullRefPtr<TupleDescriptor> descriptor)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Vector<Value> values;
|
|
|
|
|
TRY(values.try_resize(descriptor->size()));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (size_t i = 0; i < descriptor->size(); ++i)
|
|
|
|
|
values[i].m_type = descriptor->at(i).type;
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Tuple;
|
|
|
|
|
m_value = TupleValue { move(descriptor), move(values) };
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return {};
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<void> Value::assign_tuple(Vector<Value> values)
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null() || (type() != SQLType::Tuple)) {
|
|
|
|
|
auto descriptor = TRY(infer_tuple_descriptor(values));
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_type = SQLType::Tuple;
|
|
|
|
|
m_value = TupleValue { move(descriptor), move(values) };
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return {};
|
|
|
|
|
}
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto& tuple = m_value->get<TupleValue>();
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (values.size() > tuple.descriptor->size())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::InvalidNumberOfValues };
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < values.size(); ++i) {
|
|
|
|
|
if (values[i].type() != tuple.descriptor->at(i).type)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::InvalidType, SQLType_name(values[i].type()) };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (values.size() < tuple.descriptor->size()) {
|
|
|
|
|
size_t original_size = values.size();
|
|
|
|
|
MUST(values.try_resize(tuple.descriptor->size()));
|
|
|
|
|
|
|
|
|
|
for (size_t i = original_size; i < values.size(); ++i)
|
|
|
|
|
values[i].m_type = tuple.descriptor->at(i).type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m_value = TupleValue { move(tuple.descriptor), move(values) };
|
|
|
|
|
return {};
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
size_t Value::length() const
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null())
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
// FIXME: This seems to be more of an encoded byte size rather than a length.
|
|
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> size_t { return sizeof(u32) + value.length(); },
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
[](Integer auto value) -> size_t {
|
|
|
|
|
return downsize_integer(value, [](auto integer, auto) {
|
|
|
|
|
return sizeof(integer);
|
|
|
|
|
});
|
|
|
|
|
},
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[](double value) -> size_t { return sizeof(value); },
|
|
|
|
|
[](bool value) -> size_t { return sizeof(value); },
|
|
|
|
|
[](TupleValue const& value) -> size_t {
|
|
|
|
|
auto size = value.descriptor->length() + sizeof(u32);
|
|
|
|
|
|
|
|
|
|
for (auto const& element : value.values)
|
|
|
|
|
size += element.length();
|
|
|
|
|
|
|
|
|
|
return size;
|
|
|
|
|
});
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
2021-07-17 07:02:28 -04:00
|
|
|
u32 Value::hash() const
|
2021-06-17 13:23:52 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (is_null())
|
|
|
|
|
return 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return m_value->visit(
|
2022-12-04 18:02:33 +00:00
|
|
|
[](DeprecatedString const& value) -> u32 { return value.hash(); },
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
[](Integer auto value) -> u32 {
|
|
|
|
|
return downsize_integer(value, [](auto integer, auto) {
|
|
|
|
|
if constexpr (sizeof(decltype(integer)) == 8)
|
|
|
|
|
return u64_hash(integer);
|
|
|
|
|
else
|
|
|
|
|
return int_hash(integer);
|
|
|
|
|
});
|
|
|
|
|
},
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
[](double) -> u32 { VERIFY_NOT_REACHED(); },
|
|
|
|
|
[](bool value) -> u32 { return int_hash(value); },
|
|
|
|
|
[](TupleValue const& value) -> u32 {
|
|
|
|
|
u32 hash = 0;
|
|
|
|
|
|
|
|
|
|
for (auto const& element : value.values) {
|
|
|
|
|
if (hash == 0)
|
|
|
|
|
hash = element.hash();
|
|
|
|
|
else
|
|
|
|
|
hash = pair_int_hash(hash, element.hash());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return hash;
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int Value::compare(Value const& other) const
|
|
|
|
|
{
|
|
|
|
|
if (is_null())
|
|
|
|
|
return -1;
|
|
|
|
|
if (other.is_null())
|
|
|
|
|
return 1;
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
|
|
|
|
return m_value->visit(
|
2022-12-06 01:12:49 +00:00
|
|
|
[&](DeprecatedString const& value) -> int { return value.view().compare(other.to_deprecated_string()); },
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
[&](Integer auto value) -> int {
|
|
|
|
|
auto casted = other.to_int<IntegerType<decltype(value)>>();
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
if (!casted.has_value())
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
if (value == *casted)
|
|
|
|
|
return 0;
|
|
|
|
|
return value < *casted ? -1 : 1;
|
|
|
|
|
},
|
|
|
|
|
[&](double value) -> int {
|
|
|
|
|
auto casted = other.to_double();
|
|
|
|
|
if (!casted.has_value())
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
auto diff = value - *casted;
|
|
|
|
|
if (fabs(diff) < NumericLimits<double>::epsilon())
|
|
|
|
|
return 0;
|
|
|
|
|
return diff < 0 ? -1 : 1;
|
|
|
|
|
},
|
|
|
|
|
[&](bool value) -> int {
|
|
|
|
|
auto casted = other.to_bool();
|
|
|
|
|
if (!casted.has_value())
|
|
|
|
|
return 1;
|
|
|
|
|
return value ^ *casted;
|
|
|
|
|
},
|
|
|
|
|
[&](TupleValue const& value) -> int {
|
|
|
|
|
if (other.is_null() || (other.type() != SQLType::Tuple)) {
|
|
|
|
|
if (value.values.size() == 1)
|
|
|
|
|
return value.values[0].compare(other);
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
auto const& other_value = other.m_value->get<TupleValue>();
|
|
|
|
|
if (auto result = value.descriptor->compare_ignoring_names(*other_value.descriptor); result != 0)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
if (value.values.size() != other_value.values.size())
|
|
|
|
|
return value.values.size() < other_value.values.size() ? -1 : 1;
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < value.values.size(); ++i) {
|
|
|
|
|
auto result = value.values[i].compare(other_value.values[i]);
|
|
|
|
|
if (result == 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (value.descriptor->at(i).order == Order::Descending)
|
|
|
|
|
result = -result;
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
});
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator==(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) == 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator==(StringView value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
2022-12-06 01:12:49 +00:00
|
|
|
return to_deprecated_string() == value;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator==(double value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return to_double() == value;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator!=(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) != 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator<(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) < 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator<=(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) <= 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator>(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) > 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
bool Value::operator>=(Value const& value) const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return compare(value) >= 0;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
template<typename Operator>
|
|
|
|
|
static Result invalid_type_for_numeric_operator(Operator op)
|
2022-02-11 10:23:20 -05:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if constexpr (IsSame<Operator, AST::BinaryOperator>)
|
|
|
|
|
return { SQLCommand::Unknown, SQLErrorCode::NumericOperatorTypeMismatch, BinaryOperator_name(op) };
|
|
|
|
|
else if constexpr (IsSame<Operator, AST::UnaryOperator>)
|
|
|
|
|
return { SQLCommand::Unknown, SQLErrorCode::NumericOperatorTypeMismatch, UnaryOperator_name(op) };
|
|
|
|
|
else
|
|
|
|
|
static_assert(DependentFalse<Operator>);
|
2022-02-11 10:23:20 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ResultOr<Value> Value::add(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (is_int() && other.is_int()) {
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) -> ResultOr<Value> {
|
|
|
|
|
Checked result { lhs };
|
|
|
|
|
result.add(rhs);
|
|
|
|
|
|
|
|
|
|
if (result.has_overflow())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
|
|
|
|
return Value { result.value_unchecked() };
|
|
|
|
|
});
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
auto lhs = to_double();
|
|
|
|
|
auto rhs = other.to_double();
|
|
|
|
|
|
|
|
|
|
if (!lhs.has_value() || !rhs.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Plus);
|
|
|
|
|
return Value { lhs.value() + rhs.value() };
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::subtract(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (is_int() && other.is_int()) {
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) -> ResultOr<Value> {
|
|
|
|
|
Checked result { lhs };
|
|
|
|
|
result.sub(rhs);
|
|
|
|
|
|
|
|
|
|
if (result.has_overflow())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
|
|
|
|
return Value { result.value_unchecked() };
|
|
|
|
|
});
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
auto lhs = to_double();
|
|
|
|
|
auto rhs = other.to_double();
|
|
|
|
|
|
|
|
|
|
if (!lhs.has_value() || !rhs.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Minus);
|
|
|
|
|
return Value { lhs.value() - rhs.value() };
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::multiply(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (is_int() && other.is_int()) {
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) -> ResultOr<Value> {
|
|
|
|
|
Checked result { lhs };
|
|
|
|
|
result.mul(rhs);
|
|
|
|
|
|
|
|
|
|
if (result.has_overflow())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
|
|
|
|
return Value { result.value_unchecked() };
|
|
|
|
|
});
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
auto lhs = to_double();
|
|
|
|
|
auto rhs = other.to_double();
|
|
|
|
|
|
|
|
|
|
if (!lhs.has_value() || !rhs.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Multiplication);
|
|
|
|
|
return Value { lhs.value() * rhs.value() };
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::divide(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
auto lhs = to_double();
|
|
|
|
|
auto rhs = other.to_double();
|
|
|
|
|
|
|
|
|
|
if (!lhs.has_value() || !rhs.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Division);
|
|
|
|
|
if (rhs == 0.0)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
|
|
|
|
|
|
|
|
|
return Value { lhs.value() / rhs.value() };
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::modulo(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (!is_int() || !other.is_int())
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::Modulo);
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) -> ResultOr<Value> {
|
|
|
|
|
Checked result { lhs };
|
|
|
|
|
result.mod(rhs);
|
|
|
|
|
|
|
|
|
|
if (result.has_overflow())
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
|
|
|
|
return Value { result.value_unchecked() };
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ResultOr<Value> Value::negate() const
|
|
|
|
|
{
|
|
|
|
|
if (type() == SQLType::Integer) {
|
|
|
|
|
auto value = to_int<i64>();
|
|
|
|
|
if (!value.has_value())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::UnaryOperator::Minus);
|
|
|
|
|
|
|
|
|
|
return Value { value.value() * -1 };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (type() == SQLType::Float)
|
|
|
|
|
return Value { -to_double().value() };
|
|
|
|
|
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::UnaryOperator::Minus);
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::shift_left(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (!is_int() || !other.is_int())
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::ShiftLeft);
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) -> ResultOr<Value> {
|
|
|
|
|
using LHS = decltype(lhs);
|
|
|
|
|
using RHS = decltype(rhs);
|
|
|
|
|
|
|
|
|
|
static constexpr auto max_shift = static_cast<RHS>(sizeof(LHS) * 8);
|
|
|
|
|
if (rhs < 0 || rhs >= max_shift)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
|
|
|
|
|
|
|
|
|
return Value { lhs << rhs };
|
|
|
|
|
});
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::shift_right(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (!is_int() || !other.is_int())
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::ShiftRight);
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) -> ResultOr<Value> {
|
|
|
|
|
using LHS = decltype(lhs);
|
|
|
|
|
using RHS = decltype(rhs);
|
|
|
|
|
|
|
|
|
|
static constexpr auto max_shift = static_cast<RHS>(sizeof(LHS) * 8);
|
|
|
|
|
if (rhs < 0 || rhs >= max_shift)
|
|
|
|
|
return Result { SQLCommand::Unknown, SQLErrorCode::IntegerOverflow };
|
|
|
|
|
|
|
|
|
|
return Value { lhs >> rhs };
|
|
|
|
|
});
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::bitwise_or(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (!is_int() || !other.is_int())
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::BitwiseOr);
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) {
|
|
|
|
|
return Value { lhs | rhs };
|
|
|
|
|
});
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
2022-02-11 10:23:20 -05:00
|
|
|
ResultOr<Value> Value::bitwise_and(Value const& other) const
|
2021-10-21 18:06:24 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (!is_int() || !other.is_int())
|
2022-02-11 10:23:20 -05:00
|
|
|
return invalid_type_for_numeric_operator(AST::BinaryOperator::BitwiseAnd);
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
|
|
|
|
return perform_integer_operation(*this, other, [](auto lhs, auto rhs) {
|
|
|
|
|
return Value { lhs & rhs };
|
|
|
|
|
});
|
2021-10-21 18:06:24 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
ResultOr<Value> Value::bitwise_not() const
|
|
|
|
|
{
|
|
|
|
|
if (!is_int())
|
|
|
|
|
return invalid_type_for_numeric_operator(AST::UnaryOperator::BitwiseNot);
|
|
|
|
|
|
|
|
|
|
return downsize_integer(*this, [](auto value, auto) {
|
|
|
|
|
return Value { ~value };
|
|
|
|
|
});
|
|
|
|
|
}
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
static u8 encode_type_flags(Value const& value)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
auto type_flags = to_underlying(value.type());
|
|
|
|
|
|
|
|
|
|
if (value.is_null()) {
|
|
|
|
|
type_flags |= to_underlying(TypeData::Null);
|
|
|
|
|
} else if (value.is_int()) {
|
|
|
|
|
downsize_integer(value, [&](auto, auto type_data) {
|
|
|
|
|
type_flags |= to_underlying(type_data);
|
|
|
|
|
});
|
|
|
|
|
}
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
return type_flags;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Value::serialize(Serializer& serializer) const
|
|
|
|
|
{
|
|
|
|
|
auto type_flags = encode_type_flags(*this);
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
serializer.serialize<u8>(type_flags);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
|
|
|
|
if (is_null())
|
|
|
|
|
return;
|
|
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (is_int()) {
|
|
|
|
|
downsize_integer(*this, [&](auto integer, auto) {
|
|
|
|
|
serializer.serialize(integer);
|
|
|
|
|
});
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_value->visit(
|
|
|
|
|
[&](TupleValue const& value) {
|
|
|
|
|
serializer.serialize<TupleDescriptor>(*value.descriptor);
|
|
|
|
|
serializer.serialize(static_cast<u32>(value.values.size()));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (auto const& element : value.values)
|
|
|
|
|
serializer.serialize<Value>(element);
|
|
|
|
|
},
|
|
|
|
|
[&](auto const& value) { serializer.serialize(value); });
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
void Value::deserialize(Serializer& serializer)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto type_flags = serializer.deserialize<u8>();
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
auto type_data = static_cast<TypeData>(type_flags & 0xf0);
|
|
|
|
|
m_type = static_cast<SQLType>(type_flags & 0x0f);
|
2021-08-18 20:50:13 -04:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
if (type_data == TypeData::Null)
|
2021-07-17 07:02:28 -04:00
|
|
|
return;
|
2022-02-11 09:43:02 -05:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
switch (m_type) {
|
|
|
|
|
case SQLType::Null:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
break;
|
|
|
|
|
case SQLType::Text:
|
2022-12-04 18:02:33 +00:00
|
|
|
m_value = serializer.deserialize<DeprecatedString>();
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
break;
|
|
|
|
|
case SQLType::Integer:
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
switch (type_data) {
|
|
|
|
|
case TypeData::Int8:
|
|
|
|
|
m_value = static_cast<i64>(serializer.deserialize<i8>(0));
|
|
|
|
|
break;
|
|
|
|
|
case TypeData::Int16:
|
|
|
|
|
m_value = static_cast<i64>(serializer.deserialize<i16>(0));
|
|
|
|
|
break;
|
|
|
|
|
case TypeData::Int32:
|
|
|
|
|
m_value = static_cast<i64>(serializer.deserialize<i32>(0));
|
|
|
|
|
break;
|
|
|
|
|
case TypeData::Int64:
|
|
|
|
|
m_value = static_cast<i64>(serializer.deserialize<i64>(0));
|
|
|
|
|
break;
|
|
|
|
|
case TypeData::Uint8:
|
|
|
|
|
m_value = static_cast<u64>(serializer.deserialize<u8>(0));
|
|
|
|
|
break;
|
|
|
|
|
case TypeData::Uint16:
|
|
|
|
|
m_value = static_cast<u64>(serializer.deserialize<u16>(0));
|
|
|
|
|
break;
|
|
|
|
|
case TypeData::Uint32:
|
|
|
|
|
m_value = static_cast<u64>(serializer.deserialize<u32>(0));
|
|
|
|
|
break;
|
|
|
|
|
case TypeData::Uint64:
|
|
|
|
|
m_value = static_cast<u64>(serializer.deserialize<u64>(0));
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
VERIFY_NOT_REACHED();
|
|
|
|
|
break;
|
|
|
|
|
}
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
break;
|
|
|
|
|
case SQLType::Float:
|
|
|
|
|
m_value = serializer.deserialize<double>(0.0);
|
|
|
|
|
break;
|
|
|
|
|
case SQLType::Boolean:
|
|
|
|
|
m_value = serializer.deserialize<bool>(false);
|
|
|
|
|
break;
|
|
|
|
|
case SQLType::Tuple: {
|
|
|
|
|
auto descriptor = serializer.adopt_and_deserialize<TupleDescriptor>();
|
|
|
|
|
auto size = serializer.deserialize<u32>();
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
Vector<Value> values;
|
|
|
|
|
values.ensure_capacity(size);
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (size_t i = 0; i < size; ++i)
|
|
|
|
|
values.unchecked_append(serializer.deserialize<Value>());
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
m_value = TupleValue { move(descriptor), move(values) };
|
|
|
|
|
break;
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
TupleElementDescriptor Value::descriptor() const
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return { "", "", "", type(), Order::Ascending };
|
2021-07-17 07:02:28 -04:00
|
|
|
}
|
|
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
ResultOr<NonnullRefPtr<TupleDescriptor>> Value::infer_tuple_descriptor(Vector<Value> const& values)
|
2021-07-17 07:02:28 -04:00
|
|
|
{
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
auto descriptor = TRY(adopt_nonnull_ref_or_enomem(new (nothrow) SQL::TupleDescriptor));
|
|
|
|
|
TRY(descriptor->try_ensure_capacity(values.size()));
|
2021-07-17 07:02:28 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
for (auto const& element : values)
|
|
|
|
|
descriptor->unchecked_append({ ""sv, ""sv, ""sv, element.type(), Order::Ascending });
|
2021-06-17 13:23:52 -04:00
|
|
|
|
LibSQL: Rewrite the SQL::Value type to be contained within one class
Currently, the Value class is essentially a "pImpl" wrapper around the
ValueImpl hierarchy of classes. This is a bit difficult to follow and
reason about, as methods jump between the Value class and its impl
classes.
This changes the Variant held by Value to instead store the specified
types (String, int, etc.) directly. In doing so, the ValueImpl classes
are removed, and all methods are now just concise Variant visitors.
As part of this rewrite, support for the "array" type is dropped (or
rather, just not re-implemented) as it was unused. If it's needed in the
future, support can be re-added.
This does retain the ability for non-NULL types to store NULL values
(i.e. an empty Optional). I tried dropping this support as well, but it
is depended upon by the on-disk storage classes in non-trivial ways.
2022-09-21 13:48:02 -04:00
|
|
|
return descriptor;
|
2021-06-17 13:23:52 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|
2022-12-01 22:29:17 -05:00
|
|
|
|
|
|
|
|
template<>
|
2023-01-01 23:37:35 -05:00
|
|
|
ErrorOr<void> IPC::encode(Encoder& encoder, SQL::Value const& value)
|
2022-12-01 22:29:17 -05:00
|
|
|
{
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
auto type_flags = encode_type_flags(value);
|
2023-01-01 23:37:35 -05:00
|
|
|
TRY(encoder.encode(type_flags));
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
|
2022-12-01 22:29:17 -05:00
|
|
|
if (value.is_null())
|
2023-01-01 23:37:35 -05:00
|
|
|
return {};
|
2022-12-01 22:29:17 -05:00
|
|
|
|
|
|
|
|
switch (value.type()) {
|
|
|
|
|
case SQL::SQLType::Null:
|
2023-01-01 23:37:35 -05:00
|
|
|
return {};
|
2022-12-01 22:29:17 -05:00
|
|
|
case SQL::SQLType::Text:
|
2023-01-01 23:37:35 -05:00
|
|
|
return encoder.encode(value.to_deprecated_string());
|
2022-12-01 22:29:17 -05:00
|
|
|
case SQL::SQLType::Integer:
|
2023-01-01 23:37:35 -05:00
|
|
|
return SQL::downsize_integer(value, [&](auto integer, auto) {
|
|
|
|
|
return encoder.encode(integer);
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
});
|
2022-12-01 22:29:17 -05:00
|
|
|
case SQL::SQLType::Float:
|
2023-01-01 23:37:35 -05:00
|
|
|
return encoder.encode(value.to_double().value());
|
2022-12-01 22:29:17 -05:00
|
|
|
case SQL::SQLType::Boolean:
|
2023-01-01 23:37:35 -05:00
|
|
|
return encoder.encode(value.to_bool().value());
|
2022-12-01 22:29:17 -05:00
|
|
|
case SQL::SQLType::Tuple:
|
2023-01-01 23:37:35 -05:00
|
|
|
return encoder.encode(value.to_vector().value());
|
2022-12-01 22:29:17 -05:00
|
|
|
}
|
|
|
|
|
|
2023-01-01 23:37:35 -05:00
|
|
|
VERIFY_NOT_REACHED();
|
2022-12-01 22:29:17 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
template<>
|
2022-12-22 20:40:33 -05:00
|
|
|
ErrorOr<SQL::Value> IPC::decode(Decoder& decoder)
|
2022-12-01 22:29:17 -05:00
|
|
|
{
|
2022-12-22 20:40:33 -05:00
|
|
|
auto type_flags = TRY(decoder.decode<u8>());
|
2022-12-01 22:29:17 -05:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
auto type_data = static_cast<SQL::TypeData>(type_flags & 0xf0);
|
|
|
|
|
auto type = static_cast<SQL::SQLType>(type_flags & 0x0f);
|
2022-12-01 22:29:17 -05:00
|
|
|
|
2022-12-22 20:40:33 -05:00
|
|
|
if (type_data == SQL::TypeData::Null)
|
|
|
|
|
return SQL::Value { type };
|
2022-12-01 22:29:17 -05:00
|
|
|
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
switch (type) {
|
2022-12-01 22:29:17 -05:00
|
|
|
case SQL::SQLType::Null:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value {};
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::SQLType::Text:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<DeprecatedString>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::SQLType::Integer:
|
|
|
|
|
switch (type_data) {
|
|
|
|
|
case SQL::TypeData::Int8:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<i8>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::TypeData::Int16:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<i16>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::TypeData::Int32:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<i32>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::TypeData::Int64:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<i64>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::TypeData::Uint8:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<u8>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::TypeData::Uint16:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<u16>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::TypeData::Uint32:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<u32>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::TypeData::Uint64:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<u64>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
2022-12-01 22:29:17 -05:00
|
|
|
break;
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::SQLType::Float:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<double>()) };
|
LibSQL: Support 64-bit integer values and handle overflow errors
Currently, integers are stored in LibSQL as 32-bit signed integers, even
if the provided type is unsigned. This resulted in a series of unchecked
unsigned-to-signed conversions, and prevented storing 64-bit values.
Further, mathematical operations were performed without similar checks,
and without checking for overflow.
This changes SQL::Value to behave like SQLite for INTEGER types. In
SQLite, the INTEGER type does not imply a size or signedness of the
underlying type. Instead, SQLite determines on-the-fly what type is
needed as values are created and updated.
To do so, the SQL::Value variant can now hold an i64 or u64 integer. If
a specific type is requested, invalid conversions are now explictly an
error (e.g. converting a stored -1 to a u64 will fail). When binary
mathematical operations are performed, we now try to coerce the RHS
value to a type that works with the LHS value, failing the operation if
that isn't possible. Any overflow or invalid operation (e.g. bitshifting
a 64-bit value by more than 64 bytes) is an error.
2022-12-11 11:44:11 -05:00
|
|
|
case SQL::SQLType::Boolean:
|
2022-12-22 20:40:33 -05:00
|
|
|
return SQL::Value { TRY(decoder.decode<bool>()) };
|
2022-12-01 22:29:17 -05:00
|
|
|
case SQL::SQLType::Tuple: {
|
2022-12-22 20:40:33 -05:00
|
|
|
auto tuple = TRY(decoder.decode<Vector<SQL::Value>>());
|
|
|
|
|
auto value = SQL::Value::create_tuple(move(tuple));
|
2022-12-01 22:29:17 -05:00
|
|
|
|
2022-12-22 20:40:33 -05:00
|
|
|
if (value.is_error())
|
|
|
|
|
return Error::from_errno(to_underlying(value.error().error()));
|
2022-12-01 22:29:17 -05:00
|
|
|
|
2022-12-22 20:40:33 -05:00
|
|
|
return value.release_value();
|
2022-12-01 22:29:17 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-22 20:40:33 -05:00
|
|
|
VERIFY_NOT_REACHED();
|
2022-12-01 22:29:17 -05:00
|
|
|
}
|