Overview
SQL is a strongly typed language. That is, each data is associated with a data type that determines its behavior and usage. OushuDB has an extensible data type system that is more general and flexible than other SQL implementations. As a result, most type conversions in OushuDB are governed by generic rules rather than by specialized heuristics, which allow the use of mixed-type expressions even if they contain user-defined types.
The OushuDB scan/parser only breaks down lexical elements into five basic categories: integers, floats, strings, identifiers, keywords. Most non-numeric types are first characterized as strings, the SQL language definition allows declaring type names for strings, and this mechanism can be used in OushuDB to ensure that the parser runs in the right direction. For example, query:
SELECTtext'Origin'AS"label", point'(0,0)'AS"value";label|value--------+-------Origin| (0,0)(1row)
There are two text constants of type text and point. If no type is declared for a string literal, the literal is first initialized to an unknown type with storage space, which will be parsed at a later stage described later.
In the OushuDB parser, there are four basic SQL elements that require separate type conversion rules:
function call
Most of the OushuDB type system is built on a rich set of functions. A function call can have one or more parameters. Because OushuDB allows function overloading, the function name itself does not uniquely identify the function to be called, the analyzer must choose the correct function based on the parameter types provided by the function.
operator
OushuDB allows the use of prefix or postfix (unary) operators on expressions, as well as binary operators (two arguments) inside expressions. Like functions, operators can also be overloaded, so the choice of operator depends on the parameter type as well as for functions.
value store
INSERT and UPDATE statements place expression results into tables. The expression type in the statement must be the same or convertible to the type of the target column.
UNION, CASE and related constructs
Because all query results in a combined SELECT statement must be displayed in one column, the element types in each SELECT clause must match each other and be converted to a uniform set of types. Similarly, the resulting expression of a CASE construct must be cast to a uniform type so that the CASE expression itself has a known output type as a whole. The same requirement exists in the ARRAY construct.
The system table casts stores information about which conversions exist between which data types and how those conversions are performed. Additional transformations can be added by the user via the CREATE CAST command. (This is usually done together with defining a new data type. The set of built-in type conversions has been carefully crafted, so it's best not to change them.)
An additional searcher is provided in the analyzer, allowing improved determination of appropriate conversion behavior between groups of types with implicit conversions. Data types are divided into several basic types, including: boolean, numeric, string, bitstring, datetime, timespan, geometric, network, user-defined (user-defined). Each type (except user-defined) has one or more preferred types used to solve the problem of type selection. So ambiguous expressions (those with multiple candidate resolutions) can be resolved when there are multiple built-in types, but an error is generated when user-defined types have multiple options.
All type conversion rules are based on the following basic principles:
-
Implicit conversions must never have strange or unpredictable output.
-
User-defined types for which the parser has no prior knowledge should be at the "higher" type level. In mixed-type expressions, local types should always be converted to user-defined types (as long as the conversion is necessary, of course).
-
User-defined types are irrelevant. Now, OushuDB has no information available on the relationship between types, other than hard-coded heuristics for built-in types and implicit relationships for available functions and conversions.
-
If a query does not require implicit type conversion, the analyzer or executor should not perform any additional operations. That said, any type-matching, well-formed query should not spend more time in the analyzer, nor should it introduce any unnecessary implicit type conversion calls into the query.
Also, if a query normally uses a function for implicit type conversion, and the user defines a function with the correct parameters, the interpreter should replace the implicit operation of the old function with the new function.