Syntax
Arguments
db_path— Path to a file with an SQLite database. String.table_name— Name of a table in the SQLite database, or a query passed to SQLite as is (see Passing a query instead of a table name). String.
Returned value
- A table object with the same columns as in the original
SQLitetable.
Passing a query instead of a table name
Instead of a table name, the second argument can be aSELECT query that is passed to SQLite as is. The structure of the resulting table is inferred from the query result. SQLite reports a declared type only for a result column that is a direct column of a table; for an expression, a literal or an aggregate it reports nothing. A declared type that maps to String (see the type mapping) is used as is. A column without a declared type is typed from the storage class of its value in the first row of the query result: an INTEGER value gives Int64, a REAL value gives Float64, and any other value (TEXT, BLOB, NULL), as well as an empty result, gives String. A numeric declared type is checked against that first row as well, because SQLite reports a declared type for a compound SELECT too, taken from one of its arms while the rows come from all of them. It is kept when the storage class of the value agrees with it (INTEGER for an integer type, INTEGER or REAL for a floating-point type), and also when the value is NULL or the result is empty, since neither carries any type information that could contradict it; otherwise the column is typed from the storage class, like an undeclared one. The inferred type is therefore only ever widened, never narrowed. Inferring such a column starts the query in SQLite. The first row does not speak for the rest: SQLite is free to return a different storage class in every row (for example, CASE WHEN id = 1 THEN 1 ELSE 1.5 END), so a query-backed read is fail-closed for every column read through a numeric type - not only for the ones without a declared type. A value whose storage class does not match that type, or which is not exactly representable in it (an INTEGER cell of 300 in a UInt8 column, a REAL cell of 16777217 in a Float32 column), fails the read instead of being silently coerced. To read a column with values of mixed storage classes, declare it as String or cast it to text in the SQLite query. Every inferred column is Nullable. The query can be written either as a subquery, or wrapped into the query function:
SELECT ... FROM (<query>) before sending it to SQLite, so it must not end with a semicolon.
Such a table is read-only: INSERT into it is not allowed. The same syntax is supported by the SQLite table engine.
The subquery form
(SELECT ...) is parsed by ClickHouse and re-serialized before being sent to SQLite. It must therefore be valid ClickHouse SQL. To pass SQLite-specific syntax that ClickHouse does not parse, use the query('...') form, whose text is sent to SQLite verbatim.Any outer WHERE, LIMIT, aggregation, etc. of the surrounding ClickHouse query is not pushed down into the passed query — it is applied in ClickHouse after the full query result is fetched. To restrict the data read from SQLite, put the filter inside the passed query. With external_table_strict_query = 1 an outer filter on the columns of the table function is rejected with an exception instead of being applied locally, because it cannot be pushed into the passed query. The check covers the top-level WHERE predicate and each conjunct of a top-level AND. A PREWHERE on the columns of this table is not a case for this setting: this table engine do not support PREWHERE, and such a query is rejected with ILLEGAL_PREWHERE regardless of the setting. The check runs only where a filter could be pushed down at all: when this table is the only table of the query, on either side of an INNER JOIN, or on the preserving side of an outer join (the left side of a LEFT JOIN, the right side of a RIGHT JOIN). On the non-preserving side of a LEFT/RIGHT JOIN and on either side of a FULL JOIN nothing is pushed down and nothing is checked, so a filter on the columns of this table is applied locally after the join even in strict mode. Where the check runs, a predicate that references other tables joined in the surrounding query is not pushed down and is excluded from the check, whether it references only the joined side or mixes it with this table inside one non-AND expression (for example an OR); such a predicate keeps its usual ClickHouse evaluation point (WHERE after the join, PREWHERE before it) and is not rejected.Example
Query
Response
Related
- SQLite table engine
- SQLite database engine — Data types support section